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

Re: Renaming a package

Daniel Kobras <kobras@debian.org> 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.

I think the wording is a bit unclear.  Of course it works as described
if there are two or more alternative packages, possibly all providing a
particular virtual package, and you have one installed and say "apt-get
install one_other".  What happens upon upgrade is not specified in that
section, but it is clear from other information:

Before upgrade: oldpkg is installed

apt-get upgrade:

- wants to upgrade oldpkg

- checks for new dependencies: oldpkg now Depends: newpkg

- wants to install newpkg: Since newpkg Conflicts: oldpkg, it cannot be
  installed, neither before nor after upgrading oldpkg.

  Possible solutions:

  a) remove oldpkg, install newpkg

  b) keep oldpkg at old version

Of course you want it to choose a), but that is not going to happen.
apt-get doesn't now that oldpkg is a dummy package, and you never
requested newpkg to be installed.  Therefore it will choose solution b. 

In short:  The mechanism of Replaces as described in 7.5.2 only works if
the package that declares both the Conflicts and Replaces is explicitly
selected for installation, and helps to decide which of two (or more?)
conflicting packages should be removed.  It does not help in apt*
invocations where no package names are given.

Regards, Frank

Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Reply to: