Post by Guy BormannPost by Jeff JohnsonPost by Guy BormannI 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.
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.
Post by Guy BormannPost by Jeff JohnsonBut "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.
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
Post by Guy BormannPost by Jeff JohnsonPost by Guy BormannOf 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.
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).
Post by Guy BormannPost by Jeff JohnsonThe 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).
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.
Post by Guy BormannPost by Jeff JohnsonDifferent 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.
Post by Guy BormannPost by Jeff JohnsonThe 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).
Header files with per-arch content ios the majority of the problem;
examine Fedora patches if you chose not to believe me.
Post by Guy BormannWhen separating them into different packages that only burdens the
system that has them both installed. Arch/platform-dependent build
errors are easier to isolate.
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.
Post by Guy BormannPost by Jeff JohnsonThe 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 :-)
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.
Post by Guy BormannIt'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.
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.
Post by Guy BormannPost by Jeff JohnsonPost by Guy BormannThat'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?
No one called you "thick". You said "packages" not files.
Post by Guy BormannIsn'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.
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.
Post by Guy BormannPost by Jeff JohnsonThere is no assumption
that -devel packages contain on header files implied.
Sorry, I can't grok that sentence.
Sorry: what was intended is this statement:
There is no assumption that -devel package contain only header files implied.
(by anything I've said).
Post by Guy BormannYeah, I'm a pedant. So what?!
What does "pedant" have to do with multiarch discussions? You can self-identify
as whatever you wish ...
73 de Jeff