Re: Package upgrade question
On Fri, 29 Apr 2005, H. S. Teoh wrote:
> Hi, I have a question about how to handle the upgrade of one of my
> packages to a new upstream package.
>
> I am currently the maintainer of the package 'smurf', which is now no
> longer maintained upstream. For various reasons, upstream has moved to
> a new codebase called 'swami', which more-or-less replaces the
> functionality of smurf, but is essentially brand new code. Now that
> swami has gotten into testing, I'd like it to completely replace
> smurf.
>
> What's the correct approach to doing this? Currently, I have followed
> the procedure for renaming a package, as described in Developer's
> Reference 5.9.3: I got swami's maintainer to add
> Conflicts: smurf
> Replaces: smurf
> to swami, and filed a bug against ftp.debian.org to remove smurf.
>
> However, one of the ftp masters informed me that this arrangement may
> be problematic, because it doesn't provide a smooth upgrade path for
> people who are currently using smurf. What is the "correct" way of
> doing this, if there is one?
>
> The suggested way is to upload a dummy smurf package that depends on
> swami, but since swami already conflicts with smurf, this isn't really
> possible anymore.
When an "old" package becomes a dummy package which depends on the
"new" one, the new one should not just conflict and replace the old one,
but only the non-dumny versions (i.e. using versioned conflicts and replaces)
The idea is that "apt-get dist-upgrade" automatically upgrades the old
package to the dummy version at the same time the new one is installed.
Then, if you care about putting the dummy package in section oldlibs,
deborphan will trivially tell the user that the dummy package may be removed.
> Also, I wonder about the wisdom of doing this, because swami *is* a
> brand new program that is different from smurf even though it
> provides the same kind of functionality. It seems a bit awkward to
> me to have someone run apt-get upgrade, and have smurf silently
> removed and replaced by a new program which he may not know the name of.
This is up to you, but if the new package is not a replacement for the
old one (i.e. there are no common files, for example), then there
is no point in having conflicts and replaces at all.
Reply to: