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

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


On Sun, Dec 20, 1998 at 09:11:21PM -0500, Roland McGrath wrote:
> > Keep in mind that it is very likely that somewhere in the future we
> > will have to bump the libc soname for the Hurd, because the idea is to
> > switch from GNU stdio to libio (which is used for Linux).  If the name
> > is used for dpendencies, I think both glibc2 and libc6 are a bad
> > choice for the Hurd.  The current soname is libc.so.0.2 which suggest
> > that you should use something like libc0_2.
> Is this name really used for dependencies on shared libararies?  I would
> call that a design bug in Debian.  It means the packages have to be renamed
> and all the specs changed when the soname changes, when it's a purely
> binary change that could be handled transparently by dpkg without changing
> the sources at all.  It should depend on a tag "libc.so.0.2" that the
> glibc2 package would provide.  For things that depend on the -devel
> package, it really makes no sense to make them depend on a name that
> encodes the soname.

The reason is that different sonames of the same library can coexist on one
and the same system (although only one devel package can be installed
usually). The name of the package is the standard unite which determines
what belongs together. A new version of a package replaces all packages with
the same name and lesser version number.

Your suggestion is, if I understand correctly, that those two entities,
package name and soname, are made distinct, for example:

Package: glibc
Soname: 0.2

But this is only "syntactic" sugar (granted, it is a bit more clean). This
would require that dpkg knows that packages with different Soname field are
distinct. But this could be implemented in the way that dpkg constructs a
new "package name" internally, glibc0.2, which is not different from the
current situation.

To implement this would require adding some more intelligence to dpkg. This
could be done, but I don't see significant technical merit from it. The
current situation, as primitive as it is, works quite well even for
complicated transitions as libc5->libc6.


"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

Reply to: