* 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 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? > > 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'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. > 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. 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
Attachment:
signature.asc
Description: Digital signature