On Sat, Jan 23, 1999 at 08:32:32PM -0600, Steve Greenland wrote: > People were discussing the transition from the old layout to new, and > about upgrading. In particular, the fact that some packages had been > renamed, in particular xfnt-* -> xfonts-* seemed to make some people > think that it was necessary for the new packages to manually (in the > postinstall or some such) remove the old packages. I was pointing > out that if xfonts-xxx replaced and conflicted with xfnt-xxx, then > installing xfonts-xxx would cause xfnt-xxx to be removed. This is the > standard, documented behaviour of dpkg. Branden probably knows this, > because the xfonts-* packages do R/C (as well as provide) the respective > xfnt-* package. Right. Packages that need "xnftbase", for instance, will not break because "xfonts-base" is installed. They don't care about the packaging system, they just want files like /usr/X11R6/lib/X11/fonts/misc/clR8x14.pcf.gz around, and both the old and new packages do this equally well. > If you remove the Provides:, then dselect/dpkg will complain if anything > else depends upon xfnt-*. Right. > If you remove the Conflicts, then any file > that xfonts-xxx shares with xfnt-xxx will be assumed by xfonts-xxx. Any > files in xfnt-xxx that is not in xfonts-xxx will continue to be owned by > xfnt-xxx. When xfnt-xxx's "file count" drops to 0, it will be removed. > In other words, Replaces: without Conflicts: is a way to transfer one or > more files from one package to another. Right. Okay, good. My understanding of dpkg has not been incorrect, then. > Brandon, W.R.T. the dummy xfnt-* packages, do you object to their > creation, or just to you having to do the work (which I totally > understand and agree with)? I object to their creation. The work is trivial. Implementing the xbase fake package took only a few minutes, which was mainly spent updating all references to xbase to xfree86-common instead. xfnt* fake packages, as far as I can tell, would require ONLY editing of the control file. I object because I think to have them around is ugly. > 1. Any of the xfnt-* packages that the user had installed would be shown > in the "newer version available" section. Okay. > 2. Assuming the user does nothing mess with those, they would eventually > be shown a Conflict Resolution screen that would show the new xfont-* > packages selected and the xfnt-* packages deselected. User should just > hit return to accept the change. This should be fairly obvious, because > the "explanation" for the xfonts-* packages would be "Replaces xfnt-*". Won't this happen anyway? This is the bone of contention. Whether or not version 1 or 100 of xfntbase is installed, for instance, xfonts-base is going to conflict with it anyway. With the fake packages we get the bizarre situation of a package A depending on package B, while package B conflicts with package A. > 3. When the install time comes, the xfnt-* packages are removed and the > xfonts-* packages would be installed. Okay. > I've put a little thought into this (not a whole lot), and I don't see > any really clean way to do this in a single package's control file. > The only other approach that I can think would work would be for one > packages postinst to use dpkg --status to figure out which xfnt's were > installed, and then kludge together the appropriate file to feed dpkg > --set-selection to select the corresponding xfont's, and then tell the > user to run dselect Install again. I greatly fear doing anything like that. The X reorg has already shown me that dpkg is a pretty delicate beast. I've filed a few bugs against it as a direct result of issues raised by the reorg. -- G. Branden Robinson | I've made up my mind. Don't try to Debian GNU/Linux | confuse me with the facts. branden@ecn.purdue.edu | -- Indiana Senator Earl Landgrebe cartoon.ecn.purdue.edu/~branden/ |
Attachment:
pgpZpRextFYUh.pgp
Description: PGP signature