Re: RFS: cdrbq -- graphical cd burning frontend
On Sun, Dec 04, 2005 at 10:31:09PM +0100, Mario Iseli wrote:
> On Sat, 2005-12-03 at 11:24 -0800, Russ Allbery wrote:
> > I actually think I misunderstood, since I came into this discussion in the
> > middle. Upstream renamed cdrtoaster to cdrbq? If the plan is to remove
> > cdrtoaster from Debian in favor of cdrbq, alternatives (or diversions)
> > aren't the right choice. Those are both for cases where two packages need
> > to coexist for the indefinite future, providing alternative
> > implementations of the same functionality.
> > If cdrbq is the replacement for cdrtoaster, I'd create a cdrtoaster
> > transitional package from the cdrbq source package that contains just the
> > symlink and maybe a NEWS entry telling people that cdrtoaster is now cdrbq
> > and they should start using cdrbq and can then remove the cdrtoaster
> > package. And make that transitional package depend on cdrbq. After the
> > next stable release, you can remove the transitional package.
> Okey, the package cdrbq is ready now, later i'll build a dummy package
> (depending on cdrbq) to fix the problems with upgrading. Would be nice
> if someone would upload cdrbq now to archive, the dummy package will
> follow in some days.
> URL: http://server01.marioiseli.com/~mario/dpkgs/cdrbq/
What about a Conflicts+Provides+Replaces: cdrtoaster? I know that its
sometimes accepted to create dummy packages (or metapackages .. ),
but IMHO a few lines in control file is more clean than a completely
separate package. Is there some reason not to do this here?
I don't see why not. C+P+R: cdrtoaster, and then file a removal bug
against ftp.d.o seems right. Include some shell script
/usr/bin/cdrtoaster in your package:
cat >&2 <<-EOF
Warning: compatibility program $0 will be removed in later
releases; please use /usr/bin/cdrbq instead.
exec cdrbq "$@"
Then, drop the script, as well as C+P+R, after etch releases.