Re: RFC: Idea for improved diversions and alternatives handling
On Sun, Jun 22, 2008 at 07:05:29PM +0200, Goswin von Brederlow wrote:
> working on dpkg reminded me that I wanted to propose a better
> diversion and alternatives handling for debian packages. Currently
> they have to be manually added and removed in the maintainer
> scripts. This method is prone to errors and can easily leave
> diversions or alternatives behind. Instead I suggest creating two new
> control files detailing the diversions and alternatives a package
> should have.
Declarative diversions are a much-needed enhancement to dpkg; there are
cases one cannot deal with on upgrade without rm'ing one's own package files
in the prerm in order to handle diversion changes, and that's just nasty.
I'm happy to see people thinking about this.
However,
> New control file: diversions
> ============================
> A package wanting to divert files can list them in the control.tar.gz
> in a file named "diversions" using the following syntax:
> Empty lines and lines starting with # are comments. All other lines
> contain:
> [dpkg-divert option] ... file
> Dpkg will automatically add --package <package> and -add or --remove
> before file. If --rename is used without --divert <divert-to> then
> --divert <file>.<package> is added as well.
> On install dpkg will add all listed diversions before unpacking.
> On removal dpkg will remove all listed diversions after deletion.
> On updates/downgrades dpkg will add new diversions before unpacking
> and remove no longer listed diversions after deletion.
> FIXME: what if a line changes? Only allow certain changes?
... that's a rather large FIXME. Without fixing this, such an
implementation of declarative diversions would be pointless churn.
You should perhaps discuss this with Ian Jackson, there have already been
rumblings from him about implementing declarative diversions.
> New control file: alternatives
> ==============================
The need for declarative alternatives is much less clear because
alternatives can always be managed during a normal postinst/prerm stage,
and there are definitely cases when update-alternatives from a maintainer
script is still the only correct way to handle some alternatives. These
two proposals should be handled separately.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: