Re: -= PROPOSAL =- Release sarge with amd64
tb@becket.net (Thomas Bushnell, BSG) writes:
> "D. Starner" <shalesller@writeme.com> writes:
>
>> I think that's a little unfair. I assumed that people would know the
>> basic plan (yes, failure to anticipate what my audience knows and
>> doesn't know is one of my communication failures) and intend to explain
>> why they think this is a good plan, instead of technical details.
>
> Well, I'm asking now. If you want the developers to approve your
> GR--something I'm extremely skeptical about--you have to be willing to
> start filling in details. I'm not blaming you for not trotting them
> out before; I'm just explaining, if you want my support, what you have
> to tell me.
>
>> > Details would be: which parts of LSB is the port not compliant with?
>>
>> The part that requires 64 bit libraries to be installed in /lib64/
>> instead of /lib.
>>
>> > Why do the packages require changes to become compliant?
>>
>> Library packages have to install in /lib64 instead of /lib.
>
> These seem to be extremely trivial problems to fix. By comparison
> with what other ports go through, I don't really have much sympathy.
> Install the libraries where they want, and file appropriate bugs to
> get them to do so.
Thats over 2000 source packages that need major changes to the
configure scripts, debian/rules, debian/*.files,
debian/*.(pre|post)(inst|rm).
That is certainly not trivial (amount wise) and quite an unacceptable
delay for sarge.
> A reasonable technical solution would be a program that packages can
> run which tells them where to install libraries--perhaps, indeed, a
> debconf variable. I presume the porters and the technical committee
> could come up with a good way.
Not all places that use the lib path use variable subsitution. Which
means a bunch of tools have to be changed first to allow varibales.
Also something not quite favourable to a sarge release.
>> > Why is the
>> > result in question considered inelegant?
>>
>> The fact that it supports only one ABI switch and adds new
>> directories to root.
>
> I don't understand what you mean be "supports only one ABI switch",
> can you explain that more fully.
>
> As for adding new directories to root, the FHS and LSB own root (more
> or less). Saying "it's inelegant to add new directories to root" may
> be true, but here you are simply rewriting the LSB (which has already
> made that judgment, and decided against you), and regardless of
> whether the LSB is right or wrong, Debian has committed to follow it,
> for good reasons.
>
> So you will never get me to approve of not following the LSB on the
> grounds that you simply happen to disagree with the elegance of its
> solutions.
We follow the LSB for 64bit amd64 as best as we can while ignoring the
ia32 lsb. Pure64 doesn't want to be multiarch. Do you think that
biarch LSB support is realy essential to the great majority of users?
>> > A multi-arch system may or may not be a good idea, but regardless,
>> > it's irrelevant to the question at hand, which is about the inclusion
>> > of amd64 in stable now.
>>
>> The difference between what AMD64 does right now and the standard asks
>> for is that we don't do a multiarch system. (The standard asks for a
>> biarch system.) If it's not a good idea, then AMD64 shouldn't follow
>> the standard.
>
> You don't have a multi-arch system. So the decision isn't about
> whether we have one or not. Please stop trotting out vaporware as if
> it were relevant. If anything, the more you say "we will do this some
> other way when we finish coding" only convinces me that it's not
> appropriate for stable.
The full LSB asks for a biarch system. We don't follow that but do
uniarch, hence pure64.
multiarch != multiarch proposal. Very confusing since people just
use multiarch or biarch for them.
>> There won't be an AMD64 with /lib64 in sarge. It's just too
>> destabilizing. It seems counter-productive to transition to /lib64,
>> and then move all those libraries to /lib/amd64-linux-gnu/ later.
>
> I don't think so; it's trivial--if you use a configuration variable
> strategy for picking which directory to put the libraries into.
Correct me if I'm wrong but I don't think you have the experience
needed to judge this. A lot of people that have ported packages to
biarch, multiarch and pure64 agree that its not trivial and its still
not perfectly clear on how to best solve that problem elegantly.
> I agree that a multi-arch system is superior to the double-arch
> mechanism. But that isn't the question here.
Mutli-arch or double-arch doesn't make much difference. The way to go
is certainly to have a variable determining the libprefix somewhere
and then its irelevant if you compile for 2, 3 or 100 different
prefixes.
The problem is we only have one fixed libprefix for now and no
variable or even mechanism to make it a variable.
> Thomas
MfG
Goswin
Reply to: