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

Andreas Jaeger aj at suse.de
Wed Feb 20 06:22:04 PST 2008


"Theodore Ts'o" <tytso at mit.edu> writes:

> One of the really critical questions for us to consider is which version
> of Glibc to target for LSB 4.0.  Currently, LSB 3.1 and 3.2 are
> essentially based on glibc 2.3.4.  The most recent version of glibc is
> 2.7, and currently SLES 10 is based on glibc 2.4, and RHEL5 is based on
> 2.5.
>
> Now, there are a couple of things we could do.  One is we could try to
> guess what the next round of enterprise distributions will use, which is
> probably glibc 2.7.  Another is that we could target the version of
> glibc currently used by the currently shipping versions of the
> enterprise distributions, which is SLES 10 and RHEL 5.

In that case, we could also consider targetting glibc 2.8 which should
come out in the next few months (glibc is currently on a half-year
schedule).

> The upside of doing this is that if LSB 4.0 is something which SLES 10
> and RHEL 5 can currently certify against, it immensely increases our
> short-term impact on the software market.  It also makes it easier for
> us to test to make sure that LSB 4.0 will is something which current
> distro's can certify against, without having to guess what will be in
> RHEL 6 and SLES 11.  
>
> In addition, RHEL 6 and SLES 11 will not release until sometime in 2009.
> Initial public reports have these distributions releasing in early 2009,
> maybe Spring 2009 for SLES 11[1] and sometime in 2009 for RHEL 6[2].
> (Some LSB workgroup members have access to more precise dates through
> NDA arrangements with the distro's, but I'm trying to stick with public
> information here.)  The reality is that most ISV's won't release
> products for the latest enterprise distro's until 6-9 months after the
> first GA release of the distribution.  That's because many customers
> aren't eager to put the latest RHEL or SLES into production until after
> the first service pack or update release --- and besides, a binary that
> runs on RHEL 5 or SLES 10 will run on RHEL 6 or SLES 11, so there isn't
> much upside for an ISV to start releasing products based on the latest
> enterprise distro all that aggressively.
>
> The downside is that glibc 2.4 is rather long in the tooth; it was
> released in February 2006.  On the other hand, looking at what's
> actually in glibc 2.7, the surprising thing is there aren't *that* many
> new interfaces or features since 2.4, at least compared to say the
> difference between 2.3 and 2.4:
>
> * New Linux interfaces: mkostemp, mkostemp64 (glibc 2.7)
> * New Linux interfaces: signalfd, eventfd, eventfd_read, eventfd_write
> 	(glibc 2.7)
> * New Linux interfaces: epoll_pwait, sched_getcpu (glibc 2.6)
> * New generic interfaces: strerror_l (glibc 2.6) 
> * New Linux interfaces: splice, tee, sync_file_range, vmsplice (glibc 2.5)
> * RFC 3542: Advanced socket interface for IPv6 (glibc 2.5)
> * Support for the ELF .gnu.hash section (glibc 2.5)
> * Real-time priority inheritance mutexes and priority protected mutexes
> 	(glibc 2.5)
>
> 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.

On the other hand: For the success of LSB, I do think we should target
these current enterprise releases - if the schedule for 4.0 is still end
of 2008 and will be kept.

> So one thing that I think we should consider is to target LSB 4.0 so
> that SLES 10 and RHEL 5 can certify against it.  It might mean dropping
> some libraries and functionality, but we can always just defer some of
> the to LSB 4.1.  One thing that does worry is me if there are some
> land-minds waiting for us in the C++ library --- OTOH, if they
> introduced some incompatibilities, especially if they forgot to bump the
> major version number (cough, they would *never* do something like that
> :-), it will be a problem for RHEL and SLES as well.
>
> What do folks think?

Andreas
-- 
 Andreas Jaeger, Director Platform / openSUSE, aj at suse.de
  SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
   Maxfeldstr. 5, 90409 Nürnberg, Germany
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080220/0ffe92ca/attachment.pgp 


More information about the lsb-discuss mailing list