Re: Overeager cleaning of -devel provides

Jeff Johnson schreef op vr 02-08-2013 om 10:55 [-0400]:
> 
> On Aug 2, 2013, at 7:10 AM, Guy Bormann wrote:
> 
> > > 
> > I guess it helps as a distributor to have main contributors that
> > also
> > 'own' the upstream or work for the largest Linux company.
> > 
> > 
> 
> 
> Presumably you are snidely remarking on RedHat and the degree of 
> involvement in FL/OSS projects.
I am remarking on it but not snidely.
> 
> But "own" is troll bait and "largest" isn't exclusive.
I put own between quotes exactly because of the sensitivity some have
for the word. It rather shows my imperfect command of English than
anything else. I just don't know how to express the relation between the
main author or contributor to a project. Some are truely collaborative,
for others, the community is only built after the initial implementation
was released to the public by a key person or very small key team.
Apologies if it looked like troll bait.

> > Of course you can make a -devel package arch-agnostic, you just hide
> > the
> > complexity in the package (and make it bigger because you need to
> > store
> > all supported archs even if you don't need the other part)...for
> > every
> > single package instead of in the packaging system. The KISS you see
> > is
> > very superficial.
> > 
> > 
> 
> 
> This isn't the correct characterization of the problem.
I wasn't characterising the packaging problem. I was describing
techniques to make a library multi-platform/arch. That's independent of
packaging.

> 
> The issue is arch-specific differing content in include (usually, not
> always) files causing
> file conflicts.
Of course, what other conflict could there be with a bunch of text files
(assuming that is the only possible problem for source distribution of
multi-arch projects).

> 
> Different content on same path can be handled either by merging (like
> Fedora has done)
> or by adding an arch identifier and changing include paths (like
> Mandriva has done).
And, how is that different from what I wrote?
> 
> The changes are usually quite small (not "bigger") to merge, with a
> pleasant result
> that there are fewer files to examine when a build breaks.
Assuming that header files are the only problem, the changes might be
small but the installed corpus of header files will be larger for
everyone installing them with arch/platform errors harder to identify
(because of the merger).

 When separating them into different packages that only burdens the
system that has them both installed. Arch/platform-dependent build
errors are easier to isolate.

> 
> The idea that content for "all supported arches" leads to bloat
> ignores the fact that most
> user machines don't need to install -devel packages at all.
Fair enough. I don't have a strong preference. I just took issue with
the purported simplicity of the merger solution. Objectively you just
move the complexity. As a leaf dev in the dependency tree (of user vs
producer of a library), I couldn't care less who had to bear the brunt
of the packaging complexity. That's all I'm saying. But it's clear what
carries your preference :-)

It's funny how some people are allowed to say how stupid other people or
other people's decisions are while others are accused of bad manners
when they don't necessarily agree or just want to add some colour or
nuance to the monochrome picture that is painted.
 
> 
> > That's assuming -devel packages only every contain C/C++ header
> > files...
> > 
> > 
> 
> 
> Again the multi-arch issue has to do with files, not packages.
Yeah, I'm not that thick :-( In the end it's all about files. What else
is a package but a bunch of files and a local definition of the
dependency tree?

Isn't the issue with the files _in_ the packages when unpacking those
files? The common files on common paths give conflicts when installing
them from separate packages without path trickery. And all versioning
hell that implies. Not sure I can describe it by not using the word
package.

>  There is no assumption
> that -devel packages contain on header files implied.
Sorry, I can't grok that sentence.

> 73 de Jeff
> 

Yeah, I'm a pedant. So what?!