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

[Theodore Ts'o]

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.

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.

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?

						- Ted

[1]  http://linux.derkeiler.com/Mailing-Lists/SuSE/2008-01/msg01826.html
[2]  http://www.linuxpromagazine.com/online/news/red_hat_enterprise_linux_5_1_with_improved_virtualization/(kategorie)/0