Re: Dpkg Update Proposal
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.
Someone else explained that this is a non-problem, unless we're
> 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
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.
"It's like a love-hate relationship, without the love"
- Jamie Zawinski, consummate UNIX hater, on Linux