Hi Andreas,
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)
>
> 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 ...
It turns out you were right, again.
While the above indeed worked fine in all of my local tests (which, as
stated in #44, I did for all possible combinations), apparently there
are constellations possible where the rm_conffile leads to a removal
when it shouldn't.
Such a case was reported as #781050. I prepared a package which reverts
the rm_conffile, so the obsolete conffile will just be accepted for now.
The unblock bug #781448 has a longer rationale for this decision.
> I even added some workarounds in piuparts for a related issue (a
> conffile was disappearing sometimes, but never from the reference
> chroot) - since I didn't really see a fault in your packages:
>
> case ${PIUPARTS_OBJECTS%%=*} in
> kismet|\
> tshark|\
> wireshark|\
> wireshark-common|\
> wireshark-dbg|\
> libcap2-bin)
> # libcap2-bin/wheezy is part of the minimal
> chroot and recommends libpam-cap
> # a conffile moved from libcap2-bin/squeeze to
> libpam-cap/wheezy
> log_debug
> apt-get install -yf libpam-cap
> ;;
Please consideres this as a heads-up that once the above change enters
unstable with 1:2.24-8, you may or may not need to re-introduce the
work-around above.
Regards,
Christian
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
