On Wed, 2005-06-29 at 14:59 -0400, Dave Neil wrote: > Hi Matt, > Looks like the Debian project is going to have to come up with a > decision on this stuff. It looks like an endless catch 22 from my > perspective, based on everything that's been brought up in this thread. > The LSB folks aren't going to budge and if Debian wants to be LSB > compliant for 2.0 or even 3.0, there will have to be some hard choices > taken. Can we get this matter resolved from the Debian camp soon?
There /were/ a couple of tough decisions here: > >What's more, when I brought up one problem way back when (the > >requirement for NPTL > glibc 2.3.2 in LSB 2.0), I was basically told to > >adopt glibc CVS or backport. I do not recall any discussion of > >loosening the requirement, though I will admit I am working off fuzzy > >memories and not archives. Waaayyy back in 2004 :-), the two things LSB was being beaten up over not having, generally expressed as "it's useless without it, just ignore the LSB until they fix this", were a C++ ABI and pthreads. linuxthreads wouldn't pass anyone's idea of a comprehensive pthreads testsuite, it needed NPTL. We didn't really end up with a lot of wiggle room there, so we had to be a little less conservative than usual, although "available from upstream" IS always a factor. LSB has been known to get accused of being too conservative :-) For 3.0 there were some questions about glibc versions - there was pull to move forward and no real push back, absent which we moved the bar forward. We *would* listen to real pushback. Note that for all architectures but Power, the damage is limited to exactly four libc symbols and one libpthread symbol that are later than 2.3.2 (as in fact is the case for upstream). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
