Re: The fate of libc5
On Tue, 11 Jul 2000, Ben Collins wrote:
> > If it is not a serious problem I vote for leaving it in woody and remove
> > it later.
> Taking it out of woody does not make it unavailable. As with any obsoleted
> programs/libs, the archive.debian.org repository keeps them around.
And what happens if e.g. a new version of libc6 or perl or anything else
essential conflicts with libc5? If you have libc5 installed, you have to
choose between removing libc5 and not upgrading your distribution. This
can't happen if libc5 is still in the distribution.
> > BTW: has anybody noticed that because of the frequent libc changes many
> > commercial applications are *statically* linked on Linux while they are
> > *dynamic* on other Unices? This is contraproductive. (Examples include
> > Mathematica4 and the ADSM client software.)
> If they would upgrade to glibc 2.0, that would not be a problem. Things
> compiled with glibc 2.0 are generally compatible and work with later
> versions of glibc. Continuing to support libc5 is like continuing to
> support Windows 3.x. It just isn't feasible forever, and developers of
> these commercial apps can take a hint. Free Software has moved on, why
> can't commercial companies that pay developers do the same?
There's another important problem around: If you have licences for libc5
programs and don't want to pay for an upgrade to a new (libc6) version.
> Anyway, RedHat's next release (rawhide) doesn't even contain libc5, and
> RedHat relies on closed-source, proprietary applications more than we
> (they have licensing deals with them). I don't see those sorts of
> applications as a reason for keeping it around in woody anyway, since it
> will always be available in archive.debian.org for those that absolutely
> need it.
I know people who switched from Redhat to Debian only because the libc5 in
Debian is still usable.
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi