Re: Renaming a package
On Thu, Jun 01, 2006 at 03:15:02PM +0200, Frank Küster wrote:
> Daniel Kobras <kobras@debian.org> wrote:
> > On Wed, May 31, 2006 at 11:52:53AM -0700, Steve Langasek wrote:
> >> 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.
(...)
> Only when you don't read the policy with proper context, and don't think
> about how dpkg works.
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.
> > 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.
> > 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).
dpkg version 1.13.2 got rid of this restriction.
Regards,
Daniel.
Reply to: