Re: LSB 3.0 and who's doing what?
Jeff Licquia writes...
> 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.
I was paying attention, and when the glibc uplift was proposed I pointed out
that doing so would exclude sarge and asked why it had to happen. Several
people explained the good reasons for doing so and Debian was in deep freeze
so I decided to let it go as a case of poor timing. Other distros have had to
deal with this before and while it sucks Debian really was the odd-man-out
this time.
> But my work on the alterative linker/libs is based on my observation
> that the LSB seems to move more quickly than Debian,
It's not supposed to, but given the length of stable releases there are times
when the LSB needs to do thing that work with what's in unstable/testing and
not stable.
> 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.
Fixing this for any distro requires not only shorter stable release cycles,
but also syncing up our release schedule the LSB's. And we'll still
periodically get hit with the "poor timing" issue.
> 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.
At the time I was told that the way threads were being specified in the LSB
spec would allow for either the existing implementation or the new NPTL
implementation. If that's not the case then something is wrong. Are there
tests failing? If so then maybe there's a TSD or INT issue.
> 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,
As I said above, this is known. Currently in experimental and hopefully moving
to unstable soon and will be in etch.
> that libstdc++6 from sarge doesn't seem to
> implement lots of needed symbols,
This will take some work but all distros are having to deal with it so we get
to leverage their work.
> and that vsw4 basically bails half way
> through the test because it kills our XFree86 4.3-based Xvfb.
This test suite is still in development and also moving to Xorg should help.
> 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.
As I said above, I think the problem here is with the LSB and that we should
be ok. Let's start the discussion about what's failing.
> >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 think this is ok and is the only way to support LSB 3.0 on sarge. Ideally
we'd always solve things in a a stable release, but when we can't this is a
reasonable alternative for those that need the new version.
> 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.)
This shouldn't be the case, the LSB selection criteria (
http://www.linuxbase.org/futures/criteria/ ) has rules to prevent this from
happening. With a few minor exceptions (like the timing issue mentioned above)
the LSB should never add anything without it already being supported in
Debian. If it does it's a bug in the LSB and not Debian and should be pointed
out on the lsb-futures and lsb-discuss mailing lists.
I don't really thing Debian and the LSB are that far off, we just have a few
small issues that need to be sorted out.
Thanks,
--
Matt Taggart
taggart@debian.org
Reply to: