Stephen Frost <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
