Re: k9copy and vamps: how to proceed if packages are merged?
On Sat, Nov 05, 2005 at 04:36:48PM +0100, Claudio Moratti wrote:
> Hi!
> I'm working on packaging of k9copy and vamps package (ITP: 320045 and 320067).
>
> In a first time, packages was separated, but now, the upstream author has
> merged them.. The problem is that k9copy provides vamps, but with a different
> name: k9vamps and k9playcell!
>
> I'm looking for the right way to proceed...
> I can add a field in control file: "provide: vamps"..
> but after?
> maybe an alternative? I don't think is a good idea..
> a normal link? but after that there will be 4 commands: vamps, k9vamps, etc...
>
> suggestions?
AFAICT what you want to do is to cause upgrades to install the new
version of the package (whatever you call it), and cause previous
versions to be removed.
You can cause the upgrade to happen by generating packages with the
name of an existing package, and a higher version. Alternately, you
can change the package name (which may cause you to have to retraverse
the NEW gauntlet^Wqueue), but add Provides: oldpackagename. Since
oldpackagename wont exist in the new upload (except by the Provides),
and since it has a higher version, newpackage will be installed.
You can cause the old version of the package to be uninstalled by also
adding Conflicts and Replaces on oldpackage.
Provides+Conflicts+Replaces is a combination special which is
interpretted specially by dpkg ..
See policy 7.5 for more.
You might consider keeping a symlink in the newpackage for any
commands whose names have changed; maybe also use a shscript which
prints a warning: "$0 is depreciated and will be removed".
You can remove the Provides+Conflicts+Replaces foo after the next
stable release, since upgrades across stable releases are not
supported.
--
Clear skies,
Justin
Reply to: