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
blog):
| 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
job.
- 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.
Cheers,
Aurelien
[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
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: Digital signature
