Re: renaming a library package (advice and sanity check)
Santiago Vila <sanvila@unex.es> writes:
> On Sat, 15 Jan 2005, Kevin B. McCarty wrote:
>
> The point I was trying to make is that a libvips-doc which conflicts
> and replaces libvips7.10-doc would force the removal of libvips7.10-doc
> when doing "apt-get dist-upgrade", . . .
I think this may only be true if something depends upon libvips-doc.
If the dummy libvips7.10-doc depends upon libvips-doc AND the new
libvips-doc Conflicts and Replaces libvips7.10-doc, the package gets
held back with dist-upgrade. (I tried this scenario.) Explicitly
installing libvips-doc does cause the removal of libvips7.10-doc in
this case though, but that's true in the case below as well.
> . . . but a libvips-doc which only
> conflicts and replaces the non-dummy versions of libvips7.10-doc
> would make the new package to be installed, and the old package
> to be upgraded to its dummy version.
This is the strategy I'm going to use. I've run a number of scenarios
with some trivial fake packages, and I think this results in the best
possible behavior.
> Removing a package when doing "apt-get dist-upgrade" is something I
> believe people have to think more carefully than installing new
> packages. If we can delay the removal of the package to the time the
> user does deborphan, I think there is a little gain in smoothness
> for the upgrade.
>
> What is a real pity is that dpkg does not have a field like this:
>
> Package: libvips-doc
> Previously-Known-As: libvips7.10-doc
>
> It would save us the trouble of conflicts, replaces, provides and
> dummy packages alltogether.
And maybe even result in the old package completely being removed no
matter which order you do things in. I can't seem to find any setup
where all scenarios have this result. Specifically, there doesn't
seem to be any situation in which having package A installed and
running dist-upgrade could possibly result in A being removed and
replaced by B. The only way to get B would be to have something
depend upon it, and the only way to get A removed would be to have
something conflict with it. If a new A depends upon a new B and the
new B conflicts with that new version of A, the package is held back.
Your "Previously-Known-As:" idea could be made to do that. (Maybe
"Replaced-By:" would be a better name.) I may suggest this in a bug
report.
In any case, here's what I've done with my trivial test packages:
Original:
asdf1.0_1.0-1 source creates libasdf1.0, libasdf1.0-dev, libasdf1.0-tools
asdf-client_1.0-1 depends upon libasdf1.0, build depends upon libasdf1.0-dev
New:
asdf1.0_1.0.replaced-1
libasdf1.0:
Depends: libasdf1
Section: oldlibs
libasdf1.0-tools:
Depends: libasdf-tools
Section: oldlibs
libasdf1.0-dev:
Depends: libasdf-dev
Section: oldlibs
Removed dependencies on libasdf1.0 from the other packages so that
all packages have no dependencies other than those explicitly
listed here.
All packages have descriptions like this:
Description: transitional dummy package replaced by libasdf1
This is the old name for libasdf1. It can be safely removed.
as adjusted to have to correct names for each package.
asdf-1.0_1.0 source creates libasdf1, libasdf-dev, libasdf-tools
libasdf1:
Conflicts: libasdf1.0 (<< 1.0.replaced)
Replaces: libasdf1.0
libasdf-tools:
Conflicts: libasdf1.0-tools (<< 1.0.replaced)
Replaces: libasdf1.0-tools
libasdf-dev:
Conflicts: libasdf1.0-dev (<< 1.0.replaced)
Replaces: libasdf1.0-dev
asdf-client_1.0-2 depends upon libasdf1, build depends upon libasdf-dev
With this situation, apt-get dist-upgrade leaves you with all new
packages installed and all old packages replaced with dummy versions.
Explicitly installing the new packages (which only someone
specifically aware of the exact details would know to do) upgrades all
the new packages and removes all the old packages. I've tried this
with only asdf-client and libasdf1.0 initially installed, with only
libasdf1.0-tools and libasdf1.0 initially installed, and with all four
packages initially installed. apt-get dist-upgrade works as I
described in all cases.
Interestingly, deborphan only shows libasdf1.0 as an orphan even with
all three packages moved to oldlibs and with all the interdependencies
removed. apt-cache rdepends shows reverse dependencies I don't
understand. I'd have to look into exactly what rdepends looks for.
For example, I now have:
% apt-cache rdepends libasdf1.0-tools
libasdf1.0-tools
Reverse Depends:
libasdf-tools
libasdf-tools
% apt-cache depends libasdf-tools
libasdf-tools
Depends: libasdf1
Conflicts: libasdf1.0-tools
Replaces: libasdf1.0-tools
(The conflicts is a versioned conflicts, but apt-cache depends doesn't
show this. apt-cache show does.) It's like apt-cache rdepends
considers the Conflicts as a dependency, which would be a bug. I'll
look into it a little further and report it if needed. This same
thing happens with libasdf1.0 and libasdf1, so I don't know why
deborphan shows these.
Anyway, I feel confident now in proceeding with the rename knowing
that nothing will get broken by a dist-upgrade even during the
transition. The only period of breakage I can find occurs when the
new packages have appeared and the upgraded versions of the old
packages have not yet appeared. In that case, installing the tools
package from the new version would result in removal of the old
version of the client package. Again, this problem could happen only
under a short window of time, and would only happen if someone
explicitly tried to install the new package, not if someone did a
dist-upgrade. I think this kind of thing happens all the time.
Well, this is long, but maybe it will help someone reading the archive
someday.
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
Reply to: