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 [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
