[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Debian is switching to EGLIBC

Hi all,

It is new to me that we should announce changes in packages on
debian-devel. I haven't seen that before for other (key) packages, while
it is very usual to see such announcements on planet.debian.org.

I have decided to add a blog entry after many people asking me on IRC
"What is this thing in NEW?".

As it seems people are complaining, let's do it (copy and paste from my

| I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is 
| currently waiting in the NEW queue), which will soon replace the GNU 
| C Library (GLIBC). The EGLIBC is a variant of the GLIBC which stays 
| source and binary compatible with the original GLIBC. While primarily
| targeted for embedded architectures, it has some really nice points:
| - More friendly upstream (especially with regard to embedded 
|   architectures): “Encourage cooperation, communication, civility, and
|   respect among developers” (as opposed to this).
| - Stable branch with fixes for important bugs (a real one, not like the
|   GLIBC one which is left unchanged).
| - Better support for embedded architectures.
| - Support for different shells (GLIBC only supports bash).
| - Support for building with -Os.
| - Configurable components (do we really need NIS or RPC support in 
|   debian-installer?).
| - Better testsuite for optimized or biarch packages.

Let's add an other point I forget:
- Support of MPCore for ARM.

| We do not use some of these features yet, but this upload is a first 
| step. From the user point of view, the package names are unchanged
| (except the source package and the binary package containing the 
| sources) so no transition is needed.

And to answer some of the questions:
- EGLIBC is constantly tracking GLIBC. You should consider that as a set
  of patches applied on top of GLIBC.
- The API and ABI compatibility is retained as long as you don't disable
  some components, in which case you are removing functions and breaking
  API and ABI. We do not plan to disable components in the main Debian
  package, but it something that may be possible in the future for
  example in the .udeb version.
- As most as possible code (read if accepted) in EGLIBC is contributed 
  back to GLIBC. That's why FSF assignement is still needed for EGLIBC.
- I am following EGLIBC development for more than a year, and tried it
  on Debian during last Debconf. The code is already in the SVN for 
  two/three months ago.
- We could have done that silently by putting the patches in
  debian/patches (which would have skip the wait xxx days in NEW), but
  that would have been unfair with upstream EGLIBC, who is doing a great
- The package has been built on all Debian architectures [1] and checked
  for regressions in the testsuite. Some bugs have been found in the 
  biarch and optimized packages, as strangely some parts of the testsuite
  were skipped.
- strlcpy() and strlcat() won't be added to EGLIBC as it would break the
  ABI and API. Use libbsd [2] for that, it is already in the archive.


[1] alpha amd64 armel hppa i386 ia64 mips mipsel powerpc s390 sparc
    hurd-i386 kfreebsd-i386 kfreebsd-amd64
[2] http://libbsd.freedesktop.org

Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: Digital signature

Reply to: