Re: Renaming a package
Daniel Kobras <firstname.lastname@example.org> wrote:
> Steve wondered why people suggest package relationships that cause
> problems during upgrades. I claimed that policy may well be the source
> of the confusion. The fact that you can read different meanings into it
> isn't quite the point. Well, actually it proves the point of policy
> being ambiguous here.
ACK, it seems to be misunderstood, so the wording can be improved...
>> > 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?
> I don't think it's mandatory in this scenario, unlike the method
> described below where newpkg hijacks the /usr/share/doc/oldpkg symlink.
It's not mandatory, but it helps: If a third package depended on oldpkg,
it will probably also be happy with newpkg, and this way it continues to
work even if the dummy package is removed. Or in other words: Without
the Provides it's not possible to remove the dummy package as soon as
there's one reverse Depends on oldpkg.
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)