Re: RFC: Idea for improved diversions and alternatives handling
Steve Langasek writes ("Re: RFC: Idea for improved diversions and alternatives handling"):
> 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.
Absolutely. I would agree with Steve Langasek's comments, though.
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
--divert
In practice diversity in this option seems to cause more
trouble than it's worse. Perhaps we should settle on
`.diverted' or something ?
--rename
Should always be enabled in this case. The situations where
this isn't right don't apply, and for declarative diversions
we're expecting dpkg to Do The Right Thing all of the time.
--admindir --test --quiet --help --version --truename --list
Make no sense in a diversions file
Which leaves only the pathname :-).
> 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.
> You should perhaps discuss this with Ian Jackson, there have already been
> rumblings from him about implementing declarative diversions.
After my last experience I don't have any plans to do any substantial
coding in dpkg :-/.
> > 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.
Absolutely. I would suggest at least doing the design work
sequentially. Otherwise we'll all get more confused.
Steve Langasek writes ("Re: RFC: Idea for improved diversions and alternatives handling"):
> Er, I've for the life of me never understood why --rename is even an
> *option* to dpkg-divert. What does dpkg-divert do without it, and how is
> that useful?
Goswin's answer is one example - although actually the odds of a
package maintainer doing the diversion of an essential file correctly
are quite low. --rename should have been the default (sorry).
Ian.
Reply to: