Re: Renaming a package

[Daniel Kobras <kobras@debian.org>]

On Wed, May 31, 2006 at 11:52:53AM -0700, Steve Langasek wrote:
> On Wed, May 31, 2006 at 02:05:13PM +0200, Daniel Kobras wrote:
> > On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
> > > On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
> > > > Steve Langasek schrieb:
> > > > >>Package: oldpkg
> > > > >>Depends: newpkg
> > > > >>Description: transitional dummy package
> 
> > > > >>Package: newpkg
> > > > >>Replaces: oldpkg
> > > > >>Conflicts: oldpkg
> > > > >>Description: ...
> 
> > > > >*NO* *NO* *NO* *NO* *NO*.  Look closely at the package relationships you've
> > > > >specified.  Why would you upload a package to the archive that *can never 
> > > > >be installed*?
> 
> > > > Hm, that used to be a "magic" combination that would let dpkg do the 
> > > > right thing.
> 
> > > I've heard this stated before, but if it was ever true, it's definitely not
> > > the case with apt (or with britney), and it's not mentioned in policy.
> 
> > It may well cause problems to britney, but policy section 7.5.2
> > ('Replacing whole packages, forcing their removal') definitely mentions
> > the behaviour of Replaces+Conflicts.
> 
> It explains Replaces+Conflicts.  It does *not* say "create a dummy package
> that can't be installed because it depends on the thing that conflicts it".

Indeed, but current policy makes it very tempting to do so.
Replaces+Conflicts are the documented way to replace a package.
Versioned conflicts on earlier packages are explicitly discouraged, and
one needs a Depends to pull in the renamed package. Which leads directly
to the above relationships and all their problems. The Developer's
Reference also only talks about Replaces+Conflicts in the section about
renaming packages. Both documents should probably be updated, so which
one do you like best:

Method A

  Package: oldpkg
  Depends: newpkg
  Version: 1.0
  Description: transitional dummy package

  Package: newpkg
  Replaces: oldpkg (<< 1.0)

Method B

  Package: oldpkg
  Depends: newpkg
  Files:
    /usr/share/doc/oldpkg -> /usr/share/doc/newpkg
    (and nothing else)

  Package: newpkg
  Replaces: oldpkg
  Provides: oldpkg
  Files:
    (...)
    /usr/share/doc/oldpkg -> /usr/share/doc/newpkg

Method A relies on the user or external programs like deborphan to clean
up the dummy package. Method B gets rid of it automatically, using a
dpkg feature, but requires an extra symlink in newpkg.

Regards,

Daniel.