Re: -= PROPOSAL =- Release sarge with amd64
Stephen Frost <sfrost@snowman.net> writes:
[much of interest]
I replied in detail to what here D. Starner also said; so this only
mentions things that Stephen Frost said which D. Starner didn't.
> It doesn't solve all of the problem cases, and clutters up / to boot.
> Lots of technical details *have* been posted, it's not like we developed
> this in seclusion, there was a talk at DebConf about it, the proposals
> have been posted here and other places previously, and it's received
> comments from the dpkg, RM and other teams.
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.
> 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.
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
your guesses about that. Sure, I think it will be certainly changed
to be a multi-arch spec--but if even the directory names get spelled a
little differently, then you haven't gained anything. You have to be
able to exactly predict the future change, and I don't think you can.
> *Certainly* if this is the issue then please tell us and then listen to
> our arguments as to why we don't see IA32/LSB compliance as a problem.
I don't know what you mean be "the issue". This is one issue; it's
the one that perked up my ears.
Another is that all you are saying is an excellent reason to delay,
and put it in sid, but not sarge. It's *way* too late to start
talking about what goes in sarge in that way; we have no idea what
kinds of interactions there will be with it, because it hasn't been in
testing. That's why we have testing.
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.
Thomas
Reply to: