Re: RFC: Idea for improved diversions and alternatives handling
On Thu, Jun 26, 2008 at 10:05:53PM +0100, Ian Jackson wrote:
> I don't think replicating the options to dpkg-divert in the diversions
> file is the correct approach. The implementation won't be done by
> having dpkg call dpkg-divert (I hope!) and I think a less arbitrary
> set of syntaxes for the diversions file would be better.
> Looking at the options to dpkg-divert:
> --add --remove --package
> Should be inferred by dpkg and not specifiable in diversions
> In practice diversity in this option seems to cause more
> trouble than it's worse. Perhaps we should settle on
> `.diverted' or something ?
> > On Sun, Jun 22, 2008 at 07:05:29PM +0200, Goswin von Brederlow wrote:
> > > 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.
> Quite so. Changes to the diversions must be handled properly.
> Also we need to think about the semantics when a diversion is
> specified by more than one package, which might be necessary during
> package transitions.
Right. Nested diversions probably aren't a very clever idea, despite being
possible today; but how else do we handle a diversion moving from one
package to another? I guess we could require that packages which provide
the same diverted file must conflict with one another, but that seems
inelegant to me compared to the status quo if the packages don't otherwise
So if we allow multiple packages to be installed at the same time which
divert the same file, then I think we have another case for wanting to
continue supporting an optional diversion target - or at least for not using
".diverted" by default, since we wouldn't want diversions from multiple
packages to collide. Maybe ".diverted-$package", then?
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/