Re: -= PROPOSAL =- Release sarge with amd64
Stephen Frost <sfrost@snowman.net> writes:
> * Thomas Bushnell, BSG (tb@becket.net) wrote:
>> Stephen Frost <sfrost@snowman.net> writes:
>> > > 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.
>>
>> No, the point is that the library installs wherever the "install
>> libraries" configuration variable is set, and if you change the
>> variable, the library package doesn't have to be changed at all. It
>> has to be reinstalled, and you can just do that automatically when the
>> variable gets changed.
>
> Erm, perhaps.. This is an interesting idea, you'd have to pass to the
> build system the directory to use somehow external to the source of the
> package itself (otherwise you'd have to change the source which required
> an NMU, etc, not fun). I'm not sure how practical this would be, in the
Biarch had dpkg-libinfo for that. For multiarch nothing similar has
been written since the library path there is trivial to establish.
> end. It's an interesting idea though. I think one that maybe people
> tried to do w/ libtool or something else at one point? Where the script
> was in /usr/bin or something instead of distributed with the source?
dpkg-dev. autotools for biarch were patched as well to default to the
right directory so debian/rules wouldn't have to force libprefix all
the time. A similar patch for multiarch looks likely.
>> > 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.
>>
>> By "prove" you mean "test", of course, and I'm all for that. We test
>> things in sid, and if you want to put this in sid, I have no objection.
>
> Uh, I was talking about multiarch, not pure64, which is what we're
> proposing to have in sarge... Perhaps you missed that?
>
>> > Directory names and whatnot I would expect to be settled before we go
>> > through and change the entire archive for it...
>>
>> So would I. So don't start now.
>
> Uh, wasn't planning to... That's what pure64's all about- we didn't
> change anything from how it is on the other 64bit archs, and that's what
> we're talking about for sarge, *not* multiarch.
>
>> > If you expect a multi-arch spec, in any case, the issue of moving to
>> > the non-multiarch one and then to the multiarch one will exist.
>> > Regardless, really, the GR is about getting into sarge, and neither
>> > the non-multiarch /lib64 stuff nor the multiarch work would be ready
>> > any time soon for inclusion in sarge.
>>
>> Then it isn't ready for sarge. The more you patiently explain that a
>> good-looking solution isn't ready, the more convinced I become that
>> this belongs in sid, but not in sarge.
I think all amd64 porters would be happy with a sid inclusion. We can
look at amd64 and sarge a month from now when all packages have been
recompiled, signed and uploaded by an DD.
There realy is not much point talking about amd64 and sarge before the
testing scripts have moved enough packages from sid to sarge (enough
meaning at least 90%).
> I've been talking about multiarch, not pure64. Unless you mean to say
> that because the good-looking solution isn't available yet you'd rather
> wait for it before releasing anything? That seems very short-sighted to
> me, and is a disservice to our users, imv...
>
>> > I guess I have some foolish hope that maybe this is the only issue, and
>> > that we can settle it reasonably quickly.
>>
>> No, what is becoming clear to me (though I might be incorrect) is that
>> in general this isn't ready, mostly because it didn't live in sid, and
>> because suddenly at a late date people pop up and say "hey, we should
>> put this in sarge". The way to get it into stable is to get it into
>> sid and testing.
>
> We wanted it, and asked for it to be in sid. It didn't happen for a few
> months and now that's cascading to mean it's not going to be included in
> sarge. There's some concern that this was intentional and the
> proponents of the GR may have felt that way (I'm not entirely sure, not
> my GR, didn't second it either) and their intent was to force inclusion
> anyway because they feel it was wrongly kept out of sid.
>
>> To convince me to support a GR, you have to do more than just convince
>> me it's the right decision. You have to convince me that the release
>> manager and technical committee are unable or unwilling to come up
>> with any workable solution.
>
> <Shrug> Sure, though I'm honestly not entirely sure about their position
> on it beyond something similar to yours- "Let's have it in sid and see
> what happens...", yet the decision for it to be in sid isn't the RM's or
> tech-ctte's decision, aiui, it's the ftpmaster's (I think anyway?, I
> don't recall that ever being made very clear...).
>
>> It is *your* agenda to get amd64 into sarge, not mine. *My* agenda is
>> to make sure stable is stable, and standard-conformant, and
>> well-tested. If you want exceptions to two or three of those three
>> conditions, you have a very high hurdle if you want me to think that
>> the tech-ctte and RM should be overruled.
>
> For the parts of the standard that it's compliant with, it's been shown
> to be reasonably stable. The parts it's not compliant with aren't parts
> that are unstable in general- they just aren't there.
>
>> > Alright, if LSB compliance wasn't such a hurdle then why wasn't it done
>> > already?
>>
>> You can't tell me "it's a hurdle" and "it's not a hurdle" at the same
>> time.
>
> Multiarch or full LSB compliance *is* a hurdle- it's not what we're
> looking at for sarge, never were.
The system is amd64 LSB compliant while the (lbrary) packages are not.
That never was a goal.
>> I don't much mind a pure64 system; it should be really easy to conform
>> to the LSB in this regard: "ln -s /lib64 /lib", and then presto-magico,
>> everything gets installed in lib64.
Thas only works one way. Hence my saying pure64 is lsb compatible but
not fully compliant.
> Uh, that's what we did...
>
>> If that is really the only thing, then just do it. Of course, it only
>> works on a pure64 system, but it does work, and works just fine, and
>> conforms to the standard.
>
> No, it doesn't, not entirely, because the 32bit loader isn't there..
> And there are 64bit libs in /lib instead of 32bit libs... That's what I
> mean when I say that it's not LSB compliant.
>
> Sorry if I wasn't clear on that.
>
> Stephen
MfG
Goswin
Reply to: