From: sopwith@bogus.cuc.ml.org (Elliot Lee)
Newsgroups: comp.os.linux.advocacy
Subject: Re: Just when I thought RPMS were cool
Date: 3 Apr 1998 04:19:16 GMT
Organization: Columbia Union College

On Fri, 3 Apr 1998 02:08:10 GMT, Sam Trenholme <set@netcom.com> wrote:

>Personally, I do not know what Glibc offers that is worth the painful 
>transition.  Perhaps developers were getting bored with libc5.  :)

Here is some technical background, accompanied by reasons why libc5
deserves to die a nice quiet death:

libc5 has been hacked together from a very very very old glibc. It has
reached the end of its usable lifecycle. It's ugly, non-portable code.
It's not anywhere close to thread-safe sane. 

Now what does glibc offer?

- glibc offers much greater standards conformance (for example, the
  POSIX.1 test suite wouldn't even compile under libc5, but completes the
  tests A-OK under glibc.).

- glibc offers more features
	- switchable name service modules, so you
	can hook your system's passwd database into an LDAP server
	instantly
	- IPv6
	- 64-bit I/O API's

- glibc is easily portable to different arch/OS combos, and allows a port
  to provide optimized versions of the generic functions

- Corollary: glibc is faster (due to the platform-optimized
  functions such as the ).

- glibc insulates programs from the kernel, making them more portable.

- The glibc source code is sanely structured and cleaner and more secure,
  etc. etc. (The security problems in glibc have been in the RPC &
  resolver code, both taken from outside sources and rather crappy code if
  you ask me - volunteers to write from scratch are probably needed ;-)

- glibc supports multithreading properly (it has all the thread-safe
  versions of non-reentrant functions, and it is thread-safe in other
  places).

- The symbol versioning built into glibc means new releases of glibc will
  be binary compatible with older releases. 

None of these apply to libc5. (I've amazed even myself here with this long
list :-) 

Nobody is arguing that glibc has had teething pains, but it is needed to
ensure a sane future for Linux ;-) Hope these reasons are logical and help
you understand exactly why the change was needed.

>	rpm -i foo.src.rpm
>	cd /usr/src/redhat/SPECS
>	rpm -bb foo.spec
>	cd ../RPMS/i386
>	rpm -i foo.i386.rpm

Or easier yet
	rpm --rebuild foo.src.rpm
	rpm -Uvh /usr/src/redhat/RPMS/i386/foo.i386.rpm
and you don't wind up with the source and build directory hanging around
/usr/src/redhat/{BUILD,SOURCES,SPECS}

:-)
-- Elliot
Chicken Little was right.