On 2015-03-14 01:56, Andreas Beckmann wrote: > On 2015-03-13 23:49, Christian Kastner wrote: >>>> Would you by chance be available for sponsoring? (No problem if not, but >>>> if yes, please wait for an updated debdiff as the RT approved another >>>> one-line fix.) > > I'm not sure that this is the correct approach for capability.conf - > it's not an obsolete conffile, it has moved to libpam-cap instead (which > it Recommends)
Yeah, that was my first thought, too. But not removing it in libcap2-bin would still leave it around if libpam-cap were not to be installed (which is apparently not that uncommon), and that can't be right either. Then, see below. > The rm_conffile is fine as long as libpam-cap is not installed, but I'm > not sure whether this runs smoothly if libpam-cap is upgraded at the > same time ... Oh, I forgot to mention this. I too was concerned about this so I tested this with a jessie VM, and it worked fine. (Note 1: 2.19-3 is the version from squeeze, before the split) (Note 2: capability.conf was updated in the package between versions) 1. locally unchanged capability.conf: a. libcap2-bin/2.19-3 -> libcap2-bin/2.24-7, no libpam-cap => removed b. likewise, but installing libpam-cap => newer version 2. locally changed capability.conf: a. libcap2-bin/2.19-3 -> libcap2-bin/2.24-7, no libpam-cap => .dpkg-bak b. likewise, but installing libpam-cap => triggers dpkg question 2.b. is the only place were information could be lost, but that didn't happen. > That said, the versioning in the maintscript is wrong as well. This > needs to be the version where the rm_conffile call was added (plus > suffix '~' Yep, sorry about that. I uploaded a new version to mentors. It is the same as the previous one save for the fixed version number in libcap2-bin.maintscript. What do you think? Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
