[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LSB 3.0 and who's doing what?



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).  





Reply to: