[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

In any case, here's what I've done with my trivial test packages:


  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


      Depends: libasdf1
      Section: oldlibs
      Depends: libasdf-tools
      Section: oldlibs
      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
      Conflicts: libasdf1.0 (<< 1.0.replaced)
      Replaces: libasdf1.0
      Conflicts: libasdf1.0-tools (<< 1.0.replaced)
      Replaces: libasdf1.0-tools
      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
Reverse Depends:

% apt-cache depends 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

Jay Berkenbilt <ejb@ql.org>

Reply to: