Re: the Great X Reorganization, package splits, and renaming
On 23-Jan-99, 18:57 (CST), Branden Robinson <branden@ecn.purdue.edu> wrote:
> In the meantime, please explain this to me.
>
> C/R/P will automatically deinstall the old xfnt packages, WITHOUT
> installing their replacements? Is that true of the old static libs?
No. I think one of us (quite possibly me!) is confused.
My understanding was as follows:
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.
It appears that Jules Bean thought that you didn't know this, and that
this issue was your objection to providing dummy xfnt packages.
> Why? Nothing conflicts with the old ones except the new ones. If you
> don't select the new ones for installation, I don't understand why dpkg
> should see a need to kick the old ones out.
Exactly. It wouldn't.
> What would happen if I removed the Provides: but left the other two? How
> about the Conflicts:?
If you remove the Provides:, then dselect/dpkg will complain if anything
else depends upon xfnt-*. 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.
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)? Just so we're clear, if they did exist,
here is the effect that the user would see in dselect:
1. Any of the xfnt-* packages that the user had installed would be shown
in the "newer version available" section.
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-*".
3. When the install time comes, the xfnt-* packages are removed and the
xfonts-* packages would be installed.
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.
Steve
Reply to: