On Sun, 2013-06-16 at 19:24:45 +0200, Michael Biebl wrote: > Am 16.06.2013 19:15, schrieb Guillem Jover: > > This is just another case of dpkg being unable to do the correct thing > > due to untracked system files (filed in another bug report).
> > On Sun, 2013-06-16 at 17:25:31 +0200, Michael Biebl wrote: > >> But there is another package [1] shipping an empty /etc/pkcs11. Which > >> means the directory is potentially owned by another package, so I can't > >> just remove it in postinst. > >> And messing around with dpkg -S in postinst is starting to get ugly. > >> > >> If dpkg-maintscript-helper would move the file outside of /etc, this > >> issue would be solved. > >> Raphael, What's the reason you don't consider this a good idea? > > > > I think officializing dpkg-maintscript-helper was a mistake to begin > > with, and that's why I've never wasted time in what to me is a dead > > end. Instead, for 1.17.x I'm planning to finish up the conffiledb > > support and tracking of external files in dpkg proper. > > This issue is not really about external files, but handling of > conffiles. But maybe I just misunderstand what you mean with conffiledb. Well, dpkg-maintscript-helper moves files around to pathnames unknown to dpkg, so in a sense it's about untracked files. :) > Would be glad if you can elaborate on how that would influence conffile > handling, i.e: > 1/ removing of obsolete conffiles There's the two main cases here, the first removing unmodified obsolete conffiles, which I think it's pretty uncontroversial that dpkg should just remove them (I'll start a discussion on d-devel, due to the behaviour change, once I'm handling this). Then there's modified obsolete conffiles, either to be taken over by another package, or just not used any longer, which is trickier and I think would need to be handled by the maintainer telling dpkg upfront from a maintainer script or in a declarative way what to do. > 2/ renaming of conffiles (within the same package) > 3/ moving of conffiles between packages I think I've started work already on a dpkg-conffiles command that would handle some of these actions, including registering confguration files, to be able to replace ucf completely. So the maintainer would either declare this or tell dpkg through dpkg-conffiles what to do. > >> As for my case (gnome-keyring), I currently see three options: > >> a/ don't bother cleaning up /etc/pkcs11 > >> b/ don't use dpkg-maintscripts-helpers, clean up the obsolete conffiles > >> in preinst (using [2]) and let dpkg remove the empty dir > >> c/ use dpkg-maintscript-helpers and remove the directory in postinst, > >> while guarding the rmdir with a dpkg -S check > >> > >> Do you have another, better idea? What would be your recommendation? > > > > Personally I don't use dpkg-maintscripts-helpers in any of my > > packages, I find it too ugly for my taste. But given that your package > > is already using it probably c/ is good enough for now. > > As I needed a solution now and can't really wait until this support > lands in dpkg, I've decided to go with b/ in this particular case. > I know, that removing obsolete conffiles in preinst doesn't properly > handle aborted upgrades. But it seemed cleaner to me then c/ and I don't > just want to leave cruft around in /etc. Whatever works for you. :) Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
