Raphael Hertzog <email@example.com> writes: > On Mon, 21 Jan 2008, Joey Hess wrote: >> The shell functions already have a fairly reasonable interface. >> rm_conffile mypackage "/etc/pkg/conf.1" >> prep_mv_conffile mypackage "/etc/pkg_conf.1" >> mv_conffile "/etc/pkg_conf.1" "/etc/pkg/conf.1" >> This is not the best possible interface; it would of course be better if >> dpkg somehow figured this out on its own, or failing that if there was a >> control file dpkg could read to tell it what to do. But this is the >> interface that we're using, and I see no need to copy around large >> blocks of shell code to use it. > > Maybe we could integrate those shell functions into the dpkg package > itself until dpkg is fixed to handle them better. At least, dpkg could > replace them with no-op when the proper support is in place. A fix in dpkg would, IMO, be ideal. I think that the case of dropped conffiles should really be being handled properly by dpkg in any case. I'm not sure why it can't just keep track of them until you purge the package, or delete them outright. Either way, I don't see the need to leave such as basic task to be implemented by every package maintainer who ever removes a conffile. In the meantime, having the shell functions in dpkg itself would be very useful. However, how will etch->lenny upgrades work without a new dpkg containing the functions? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Description: PGP signature