Re: libc6.1 vs. libc6
On Tuesday, 25 Mar, Doug Larrick wrote:
> Just curious, why is it 'libc6.1' on Alpha and 'libc6' everywhere else?
Historical reasons, of course. When Linux was all libc5-based, libc5 did
not work on Alpha so Alphas had to use pre-release versions of glibc 2
(numbered 1.x with x > 90 or something). Glibc 2 was to become libc6 on
Linux when it's released, so in preparation for that its pre-releases were
configured for the soname version 6 on Linux. Naturally, there was an
interface change in glibc 2 release (what's the point in having
pre-releases if you couldn't even introduce incompatible interface
changes?). After glibc 2 was released, i386 and m68k migrated straight
from libc5, but Alphas already had libc6. The library maintainers had to
bump up the soname on Alpha to 6.1.
By the Debian policy, a shared library package name must contain the exact
major soname of the library.
> I filed a bug against razor (already fixed, fast maintainer) because it
> Depends: on libc6 >= 2.3, which doesn't work on Alpha.
> Could our libc6.1 package Provides: libc6? Would that help situations
> like this?
There was a discussion of this on this list around '97-98 - when a hell of
a lot of packages still had hardcoded Depends. I don't remember though
the arguments for/against Provides and whether they are still valid these