Re: Overeager cleaning of -devel provides

On Aug 2, 2013, at 7:31 PM, Guy Bormann wrote:

> Jeff Johnson schreef op vr 02-08-2013 om 10:55 [-0400]:
>>=20
>> On Aug 2, 2013, at 7:10 AM, Guy Bormann wrote:
>>=20
>>>>=20
>>> I guess it helps as a distributor to have main contributors that
>>> also
>>> 'own' the upstream or work for the largest Linux company.
>>>=20
>>>=20
>>=20
>>=20
>> Presumably you are snidely remarking on RedHat and the degree of=20
>> involvement in FL/OSS projects.
> I am remarking on it but not snidely.

The remark is either irrelevant or snide: the size of Fedora/RedHat
and defacto "own"ership has almost nothing to do with the multiarch
implementation in Mandriva.

So Irrelevant if not snide.

>>=20
>> 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.
>=20

Your English is not imperfect. Biut note that
my quotes are literal, not what is called "scare quotes"
	http://en.wikipedia.org/wiki/Scare_quotes

>>> 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.
>>>=20
>>>=20
>>=20
>>=20
>> 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.
>=20

You mentioned "... make a -devel package arch-agnostic, you just hide =
the complexity
in the package" and then when on to several further mentions of =
"package". Forgive
me for not understanding your characterization then: its not a packaging =
problerm
(but my point is that Mandriva is trating the issue as if it were a =
packaging problem).

>>=20
>> 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).
>=20

There are package Conflicts: for starters. Not the only problem at all.

There's lots of other possible content than include files. Meanwhile =
there
is an expectation that builds are universal, work anywhere, batteries =
included.
This is _NOT_ true with Mandriva's chosen multiarch solution, which =
"works"
by augmenting C*FLAGS, and is otherwise limited to Mandriva based =
distros
(I do not know of any non-Mandriva distro that has adopted the =
multi-arch solution).

This is accomplished within Mandriva multiarch packaging by adding
some modest complexity using macros to augment C*FLAGS, as well as to =
add what
POK has called "canonical" dependencies.

>>=20
>> 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?

You said nothing positive about patching include files, chose
instead to point out (quoting)
	make it bigger because you need to store all supported arches

In fact the portion of include files that is arch-specific is usually =
only
a small percentage of the text in an include file, and distributing
multiple copies of identical content tainted with a small portion
of code that is arch-specific is actually more, not less, code measured =
by number of
bytes.

Perhaps you think you said what I just wrote, I cannot tell.

>>=20
>> 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).
>=20

Header files with per-arch content ios the majority of the problem;
examine Fedora patches if you chose not to believe me.

> 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.
>=20

There is minimal "burden" when headers are patched to support
multiple arches. In fact (if done correctly) there's on a single file
with identical content and no change to C*FLAGS needed, rather
than changing builds to change C*FLAGS to include per-arch
content before generic content.

>>=20
>> 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 :-)
>=20

You "... couldn't care less ..." about complexity in package builds.

Complexity costs a lot when debugging, and when (as currently)
only Mandriva based rpm distros support multiarch packaging.

> 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.
>=20

I'll call yopur "stupid" bluff: show me any occurrence of "stupid" in =
what
I have replied to you.

But adding "colour" to the discusssion has little to do with other =
arguments.

It is a fact that there are no other rpm based distros that I am aware =
of who have
chosen to ado[py Mandriva's multi-arch build scheme after multiple years =
since
first deployed.

>>=20
>>> That's assuming -devel packages only every contain C/C++ header
>>> files...
>>>=20
>>>=20
>>=20
>>=20
>> 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?
>=20

No one called you "thick". You said "packages" not files.

> 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.
>=20

File conflicts are detected while installing (or "unpacking") yes.

However identical files are routinely handled while files with different =
content
(or metadata) trigger an error while installing.

And we return to the essential difference: between Fedora and Mandriva =
multiarch solutions:

	Fedora merges content to remove arch-specific content while =
Mandriva puts content on different paths.

The Fedora solution usually simplifies build complexity and minimizes =
debugging time (in my experience).

Whether you agree with my opinion, adopting Fedora patches to make =
include
files has the distinct benefit of simplifying builds: the Fedora scheme =
(from the "largest"
distro which "owns" many projects if you mist) is far more widespread =
than the Mandriva multiarch scheme.

>> There is no assumption
>> that -devel packages contain on header files implied.
> Sorry, I can't grok that sentence.
>=20
Sorry: what was intended is this statement:

	There is no assumption that -devel package contain only header =
files implied.

(by anything I've said).

>> 73 de Jeff
>>=20
>=20
> Yeah, I'm a pedant. So what?!
>=20

What does "pedant" have to do with multiarch discussions? You can =
self-identify
as whatever you wish ...

73 de Jeff
>=20
>=20