On Thu, 21 Aug 2003 17:56:15 -0400, Joey Hess said: > The problem with this idea is much the same as the problem with > a dh_alternatives: dpkg-divert and update-alternatives are complicated > and have many options that might need to be passed in, and adding a > debhelper command just adds a layer of complexity with no real gain.
> Also of course, use of diversions should not be encouraged.. Could you please explain better this point ? How a package which should configure or extend another one (think of a company custom "config-bind*.deb" package which setup a standard dns service for company's servers) should do it in a polite way? Providing directly other packages configuration files does not work, since they wil conflict with other package's files. Copying files over in postinst is suboptimal since you will lose modification in upgrades, or duplicate dpkg's work on handling condifuration files. Diversions in /etc seemed the right thing to do, so both are configuration files and dpkg will know of the diversion. What you would suggest, for better addressing both this example use case, and the general use cases handled by dpkg-divert ? -- ESC:wq -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
