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?

Thanks
Dave
Jeff Licquia wrote:

On Mon, 2005-06-27 at 17:48 -0600, Mats Wichmann wrote:

By the way, if people think we should be more conservative in glibc
"advancement", it would be good to let the LSB project know that. There
hasn't been a lot of negative input on the LSB2 and LSB3 requirements in
that area, and some fairly vocal pleas to move forward because of what
was claimed to be crucial support on certain architectures.

Well, that's probably my fault, for paying less close attention to LSB
stuff in recent months.
But my work on the alterative linker/libs is based on my observation
that the LSB seems to move more quickly than Debian, and that no stable
release since the LSB started has been up-to-date enough to conform with
the LSB version that's current at the time of release. That trend
hasn't changed with sarge, as Dave's tests prove.
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.
The problem will be even worse with LSB 3.0. I note in my tests (which
I need to post the results of; bad me!) that LSB 3.0 now requires some
symbols from glibc 2.3.4, that libstdc++6 from sarge doesn't seem to
implement lots of needed symbols, and that vsw4 basically bails half way
through the test because it kills our XFree86 4.3-based Xvfb.
Now, I realize that the problem is exaggerated with sarge due to the
long lag, and that the LSB is not entirely to blame for that. But the
NPTL problem in LSB 2.0, which looks to be the most difficult hurdle to
overcome for sarge, was very new when it was adopted, and a newer
release of sarge would not have overcome that problem.

From my perspective, using a different set of libraries for LSB programs

seemed to be the most productive way forward, since I didn't feel that I
could either hold the LSB to Debian's pace or speed Debian up to the
LSB's pace. So, that's what I'm doing.
I will say that it seems that the LSB is now a lot more prescriptive
than descriptive. In one sense, the LSB is saying that Debian is not a
proper Linux, given that it ships with an older XFree86 and doesn't have
certain NPTL features. Given Debian's place in the distro world today,
is that really appropriate? (And yes, I will again note that Debian has
brought some of this on itself with its release process.)