[lsb-discuss] What version of glibc to target?

Theodore Tso tytso at MIT.EDU
Fri Feb 22 04:01:11 PST 2008


On Wed, Feb 20, 2008 at 03:22:04PM +0100, Andreas Jaeger wrote:
> > It's rather unfortunate that SLES 10 is at the glibc 2.4, level, since
> > some of the features in glibc 2.5 are interesting; but it's not clear
> > how many of the glibc 2.5 features are really critical for ISV's --- and
> > even if they are, for the syscall related ones (i.e., splice, tee,
> > et. al), it's relatively easy for the ISV to link against supplemental
> > libraries to provide these functions.
> 
> The question is whether we can certify SLES10 and RHEL5 against LSB 4.0
> at all.  Newer glibc versions contain some major rewrites of subsystems
> so that glibc performs better and follows the standards better -
> something that cannot be easily backported.  So, it might be that the
> LSB tests require this new standard behaviour which nobody can provide
> with an old glibc.
> 
> Another challenge is that LSB requires in some areas quite new software.
> For example cups might depend on a newer version than is currently in
> use with RHEL5 and SLES10 - and the enterprise distros normally do not
> update cups.
> 
> So, let me rephrase my question: Will it possible to certify LSB 4.0 for
> SLES10 and RHEL5 if we stay with glibc 2.4 - or are there other
> requirements that make it rather difficult to certify these systems.

Well, if we keep LSB 4.0 at glibc 2.4, that should be easy, given that
SLES 10 is *at* glibc 2.4.  The substance of my proposal is that we
not go crazy and leap to glibc 2.7 for LSB 4.0, but explicitly
*engineer* LSB 4.0 so that we know that RHEL5, SLES 10, and Ubuntu
Hardy can certify.

So for example, I'd prefer being able to push for LSB 4.0 to target
glibc 2.5, since among other things glibc 2.5 has the real-time
priority inheritance mutex support.  But given that SLES 10 is at
glibc 2.4, we wouldn't do that.

My guess is if we do this, it's likely that the push to glibc 2.7/2.8
would happen in an LSB 5 that would be targetted at at the end of
2009.  That is, that we would do a 12 month LSB 4 cycle which is
targetted to complete at the end of 2008 that would be explicitly
engineered to pair with RHEL5/SLES 10; the main difference would be
adding interfaces added in glibc 2.4, expanding the libraries covered
by the LSB, and improving the ISV tools.  And then probably, we would
do another 12 month cycle LSB 5 cycle that would be explicitly
engineered to target RHEL6/SLES 11, that would hopefully be done by
the end of 2009.

						- Ted



More information about the lsb-discuss mailing list