On Thu, Jun 26, 2008 at 10:05:53PM +0100, Ian Jackson wrote: > 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 ?
What should happen when several packages divert the same file ? Which one wins ? What about original files, what do they become ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]