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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]