Re: -= PROPOSAL =- Release sarge with amd64
Stephen Frost <sfrost@snowman.net> writes:
> * Thomas Bushnell, BSG (tb@becket.net) wrote:
>> Sure, and I am happy to have dpkg, the RM, the technical committee,
>> etc., make the decision, which is why I haven't given it thought. But
>> when it becomes a GR, you have the necessity to start over, since you
>> are now asking the developers in general to overrule those people. If
>> you want my support, this is what you have to give me.
>
> Eh, the GR wasn't my idea, but, what the hell, it's fun to go through
> things over and over again, isn't it?
>
>> > It's expected that the LSB is going to be changed. Additionally,
>> > compling with the LSB isn't really an option- it'd probably take a year
>> > or more to modify all of the packages, not to mention the Debian
>> > infrastructure packages. Then we'd turn around and do it again to
>> > support multiarch, not exactly a useful way to spend our time.
>>
>> No, if you do it right, then you can install the libraries with a
>> configuration variable, so that the packages only have to be changed
>> once, to use the variable, and when you change the directory, you can
>> do it in the right place.
>
> Eh, you still have to go back through and change them all, and that's
> rather annoying, to say the least.
Which also neglegts that the library path is used in many places where
no variable substitution is possible, like dh_movefile or dh_install
files.
>> Also, your expectation about that the LSB is "going to be changed"
>> isn't worth much, unless you can somehow promise not only that it will
>> be changed, but that what you want to do now *IS* what it is going to
>> be changed to--in absolutely every relevant particular. I don't trust
>
> It will be beneficial to have the solution 'proved' to some extent
> before the LSB folks will want to commit to it.. We havn't really
> proven it yet (though there's nothing that's come up so far as a show
> stopper yet, and we don't expect any...). It's my understanding that
> there has been talk with LSB and w/ RH and that they're open and
> interested in the idea.
>From the feedback we got the LSB people are open to the
suggestion. Also, since the multiarch approach is bigger than the LSB,
compliance with the old LSB can be achived with links quite
easily. That needs to be done for a transitional period anyway to
support both the old and the then new LSB.
>> Still, conformity with the LSB is a very important thing, and I'm
>> really not convinced by your assertion that somehow it's a huge
>> hurdle. I have no confidence that you will accurately predict what
>> the next LSB will look like (in every detail) so whatever you do now
>> is equally likely not to match the future LSB as if you simply
>> conformed to the present LSB.
Compliance to LSB for amd64 _and_ ia32 is a huge hurdle. Needed
changes range from every library package up to every package depending
on the method used. The bare minimum is about 2000 source packages
need to be adapted and about 2000 new binary packages must be
introduced (or the amd64 needs to increase 50% in size).
> Alright, if LSB compliance wasn't such a hurdle then why wasn't it done
> already? There were people working on it close to a year ago (I
> remember popping into #debian-amd64 to discover people actually there,
> and dutifully working on biarch/LSB-compliant stuff). About 6 months
> ago it had pretty much entirely died off and there wasn't much interest
> in it. Then pure64 came along, got fully built and up to speed very
> quickly. Shortly following there was much discussion about biarch and
> the flaws it has and then Tollef wrote up multiarch and circled it
> around, had meetings with dpkg developers and other folks and continued
> to work on it, getting input from the RM team, etc, and now we've got a
> number of people working on it.
To be fair biarch was superceeded by the multiarch proposal. A lot of
people working on biarch went to work on pure64 and the rest switched
over to multiarch since, for anyone involved, is far superior and
easier.
> And this is just getting the *base* system to be either biarch or
> multiarch compliant, much less the rest of the archive which will also
> take a fair bit of work.
>
> Stephen
MfG
Goswin
Reply to: