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

Re: libc6_2.0.106-0.1_i386.deb is released



On 17 Dec 1998, Gordon Matzigkeit wrote:

> Since we're talking about names anyway, I just wanted to ask if
> `glibc2' is the best name for the Hurd's C library package.  I'm not
> sure what the convention for arriving on that name is, or if it's just
> an arbitrary one that looks good.

I considered the following names:

libc6
glibc2
libc2

The first one is the "Linux" name. I don't think we should choose a Linux
name if we can choose a GNU/Hurd name instead without great problems (and
we *can* do it without great problems).

The third one, libc2, would be very strange, because it would seem that
libc6 (also in Debian, but in other archs) is four versions ahead of the
GNU/Hurd version (when in fact they are in sync).

Since all the documentation about Linux speaks about "libc6 being
equivalent to glibc2", I think that glibc2 is the best name for
GNU/Hurd. Maybe it would be also the best one for GNU/Linux as well, but I
have not even thought about suggesting all the Linux people to change
at this moment ;-)

>  SV> Just remember to make glibc2-dev to Provide: libc6-dev, since
>  SV> there are still some packages having a hardcoded dependency on
>  SV> libc6-dev.
> 
> Hmm... this is confusing to me.  Why should have a separate libc
> package name for the Hurd if we just have to add `Provides' lines
> anyway?

Because the -dev package for a lib package is usually named after the lib
package, so for glibc2 we have glibc2-dev.

Normally the dependencies on shared library packages are calculated
automatically via the shlibs mechanism. This does not happen for -dev
packages, so some packages have a hardcoded dependency on libc6-dev, but I
consider this to be a bug that should not prevent us to choose the name
we feel to be the best.

glibc2-dev would be the only package having this Provides: line, and only
for compatibility with "stubborn" packages having this hardcoded
dependency on "libc6-dev".

-- 
 "fd97dc5627abc7f99d4b083266eceb0a" (a truly random sig)


Reply to: