On Wed, Jan 20, 1999 at 04:03:26PM -0500, fantumn Steven Baker" wrote: > Package Naming Scheme
The problem is superficial. Sure, names should be more uniform, but all this requires is 1) ratifying naming standards and 2) ensuring that the packaging system handles name changes gracefully. > CVS Someone else explained that this is a non-problem, unless we're misunderstanding you. > My solution, after long thought and working out, is to simply modify the > Debian Package Management system to allow multiple versions of packages to be > installed. RPM, as others have noticed, does this. Having considerable experience with RPM (I'm not proud of this), I'd like to offer my thoughts. First, technically, RPM handles it cleanly. In fact, it does not distinguish the case of two versions of the same package from the case of two unrelated packages. Two packages may share a file if the versions from the two packages are the same (by checksum). A file owned by multiple packages is not deleted until the last package owning it is removed. If you try to install a package with a file owned by an installed package, and the versions of the file are different, rpm returns an error. If you override, the new package gains sole ownership of the file. If you delete this new package, the file is deleted, since it's (only) owner is gone. The last behavior is perfectly consistent, yet horribly wrong to the user. Due to this, RPM "support" for installing multiple versions of the same package is largely illusory. Different versions of a package typically contain different versions of the same files (libraries are often an exception), and the package system can't reconcile this. So, the ability to have multiple versions of the same package installed is only useful if the packager has ensured that file ownership conflicts do not occur. RPM offers no way to "advertise" that different versions of the package can coexist. In the dpkg mindset, if the packager has gone through this trouble, he should simply release the package with a different name (eg, the ncftp packages, and hopefully the perl packages soon :) ). This makes it fairly obvious that the two versions can coexist. I find this far preferable to offering pseudo-support for multiple versions of the same package (the sort of half-solution that makes RPM such a muddled mess). Of course, we would like to have the best of both worlds: the notion that two packages really are the same packages (simplifying upgrades and dependancies), but that they can coexist. I don't know dpkg deeply, but I believe that the facilities for this exist or can be added tastefully. There are two approaches: either fork a separate package name and add headers that indicate it is an upgrade to the original package; or keep the package name the same and add a header that indicates it is a coexist-able variant. The second may seem more desirable at first glance, but it would confuse existing tools, and I bet equally nice front ends could be written for either, so I believe the first route holds more promise in the short term. Anyway, this requires more thought, and since many people have been thinking about dpkg more than I, I'll defer now. The point is, supporting multiple versions of the same package is a nice enough idea, but it's really not too far from what we already have. Andrew -- "It's like a love-hate relationship, without the love" - Jamie Zawinski, consummate UNIX hater, on Linux