Re: Renaming a package
Daniel Kobras <kobras@debian.org> wrote:
> On Wed, May 31, 2006 at 11:52:53AM -0700, Steve Langasek wrote:
>>
>> > > > >>Package: oldpkg
>> > > > >>Depends: newpkg
>> > > > >>Description: transitional dummy package
>>
>> > > > >>Package: newpkg
>> > > > >>Replaces: oldpkg
>> > > > >>Conflicts: oldpkg
>> > > > >>Description: ...
[...]
>> 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.
Only when you don't read the policy with proper context, and don't think
about how dpkg works. The phrase where versioned conflicts are
discouraged is:
,----
| A Conflicts entry should almost never have an "earlier than" version
| clause. This would prevent dpkg from upgrading or installing the package
| which declared such a conflict until the upgrade or removal of the
| conflicted-with package had been completed.
`----
So it is clear that, when both oldpk and newpkg come from the same
source package, this problem is not a big one. I'm also not sure how
"never" this "almost never" in fact is. I've encountered many actual
file conflicts which were resolved in later uploads; restricting the
Conflicts: to the last buggy version and older is actually a weaker
restriction than keeping the conflict without a version (and without a
reason!).
On the other hand, you're reading 7.5.2 with a too narrow point of
view. It does not talk about renaming packages at all, but instead
about completely replacing an other package. It also gives one common
use case, namely: Replacing an other package that Provides: the same
virtual package.
If you are renaming a package, and keep a dummy package with the old
name, this is *not* the case 7.5.2 talks about. the title is:
,----
| 7.5.2 Replacing whole packages, forcing their removal
`----
But if you have a dummy package, you don't want to force it's removal.
It's useless after the upgrade, and the local admin can remove it. But
the purpose of your Dependency relationship construction is that oldpkg
should be upgraded (to the version that is a dummy package) and
therefore pull in newpkg; not that it should magically pull in newpkg
and disappear at the same time.
> The Developer's
> Reference also only talks about Replaces+Conflicts in the section about
> renaming packages.
Yes, that's worded badly - it will only work this way if no dummy
package is needed, for example when the package name was really
misspelled, and other packages depend on the correct name.
> 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)
Why no Provides: here?
> 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
Note that if newpkg has some files that oldpkg also had, newpkg has to
conflict anyway (at least with older versions of oldpkg, see above).
> 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.
Both have their advantages and drawbacks, I don't know.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Reply to: