Re: libc soname conventions [was: libc6_2.0.106-0.1_i386.deb is released]
On Wed, Dec 23, 1998 at 02:18:37PM -0600, Gordon Matzigkeit wrote:
> Hi!
>
> >>>>> Roland McGrath writes:
>
> >> I'm now using libc0.2 as the package name, which I agree is
> >> correct.
>
> RM> Really? Truly? I will defer to the wisdom of those with
> RM> experience with debian, since I have none. But is it really the
> RM> case that debian has no better provision for this for dealing
> RM> with different versions and machine/os builds of the same
> RM> package? That is a serious shortcoming.
>
> Your points are well-taken.
>
> The only reason I can think of for why ABIs are not treated as virtual
> packages that others depend on, is that organizing the package
> archives would require more thought. There would have to be
> provisions for packages that have the same names but different sets of
> dependencies.
>
> The current system relies on the fact that the `architecture' field
> completely different than any other kind of dependency. So, we have
> to change the name of the package in order to get real flexibility in
> how dependencies are handled.
Please remember that Debians packaging system was invented for i386 Linux
systems, and later for multiple architectures that means CPUs to run on.
Because different architectures means different CPUs it is indeed true that
packages for one architecture can't run on another architecture (beside
emulation :) Therefore, the current system works well and has no
"shortcoming" in the sense I write above.
However, now that we have a different underlaying OS, the situation changes.
This is a new change, and therefore the infrastructure has to be developed.
Earlier, there was no need for the fine differentiation in architecture.
Luckily, there are other cases were a finer graduation is useful: Developing
a pentium optimized distribution, which also requires a different
understanding of architecture. i586 could run i386 programs, but probably
not vice versa. So, more people than only hurd people will be interested in
these changes to dpkg. However, changing dpkg and the ftp installation
procedure is far from easy, and somebody has to do the work.
> This is common Debian practice... my e-mail was only intended as a
> guideline of how we might apply this practice to the Debian GNU/Hurd
> distribution. I raised this issue so that we don't find ourselves
> backed into a corner of the package namespace later on, when we want
> better integration between GNU/Linux and GNU/Hurd.
Your suggestion has the fundamental flaw that it changes the name of the
packages, which breaks a lot of other things, for example the bug reporting
system (it does not really break it butm akes it more inconvenient to work
with). Changing the package names requires a change to the source, but we
can only build from one single source. Also, I dislike the fine graduation
with "p" and "i" and possibly more flags. Furthermore, I don't understand
why this would be necessary.
Debian has some experience with incompatible upgrades of the c library, the
libc5->libc6 transition was very educating.
Why can't we just bump the soname each time the hurd-i386 glibc packages
have an incompatible API change? Note that you can have multiple libc6
packages with different sonames installed, so old binaries will continue to
work. The versioned dependency should be enough to handle all cases.
We would then have libc0.2, libc0.3, libc0.4 etc packages, and binary
packages depending on them. We would only maintain one set of development
packages. Can you explain the drawbacks of this simple solution?
> Debian is also an evolving thing, and I believe that once we get far
> enough down this road, more people will grasp the problem and want to
> fix it. At that point dpkg's notion of architecture can be integrated
> with the dependency system.
This is a good goal, but I think it is irrelevant to our simple problem of
small incompatibilities between libc6 upgrades. It should be handled in the
same way we handle library ugrades under i386 linux. You will find libgtk
1.0.6 in our archive and libgtk 1.1. Both are incompatible, nevertheless
both can be installed w/o problems.
Marcus
--
"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: