Bug#703022: debian-policy: Appendix G: Diversion example faulty (doesn't work for conffiles)

[Torsten Jerzembeck]

Package: debian-policy
Version: 3.9.1.0
Severity: minor

The example provided in Appendix G of the DPM regarding the removal of
diversions doesn't work if the file diverted is a conffile. This is
due to the fact that conffiles are not removed during a "remove", but
but only during a "purge". As a "purge" implies a "remove" beforehand
(the postrm script is called twice), the example will fail even on a
"purge" with dpkg-divert refusing to clobber the existing conffile.

IMO a footnote should be added alerting the user to this fact and
providing a solution for this special case (use "purge" instead of
"remove" as the first test).

Greetings from Karlsruhe,

=ToJe=

-- System Information:
Debian Release: 6.0.7
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn doc-base <none> (no description available)

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Russ Allbery]

Torsten Jerzembeck <to...@nightingale.ms.sub.org> writes:

> The example provided in Appendix G of the DPM regarding the removal of
> diversions doesn't work if the file diverted is a conffile. This is
> due to the fact that conffiles are not removed during a "remove", but
> but only during a "purge". As a "purge" implies a "remove" beforehand
> (the postrm script is called twice), the example will fail even on a
> "purge" with dpkg-divert refusing to clobber the existing conffile.

> IMO a footnote should be added alerting the user to this fact and
> providing a solution for this special case (use "purge" instead of
> "remove" as the first test).

The last time I looked at this (which was several years ago), diverting
conffiles had enough problems that it was tempting to just say that it
didn't work reliably. I wonder if we should explicitly recommend against
diverting conffiles, or if some of those problems have been cleaned up.
Some Debian sites, such as (IIRC) MIT, have extensive local infrastructure
based on diverted conffiles and have run into all sorts of weird edge
cases with them.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

[Adam D. Barratt]

On 14.03.2013 17:34, Russ Allbery wrote:
> The last time I looked at this (which was several years ago),
> diverting
> conffiles had enough problems that it was tempting to just say that
> it
> didn't work reliably. I wonder if we should explicitly recommend
> against
> diverting conffiles, or if some of those problems have been cleaned
> up.

fwiw, Policy 10.7.4 does say "[t]wo packages that specify the same file
as a conffile must conflict. [...] Neither alternatives nor diversions
are likely to be appropriate in this case; in particular, dpkg does not
handle diverted conffiles well" but it's possibly not so easy to spot.

Regards,

Adam

[Guillem Jover]

On Thu, 2013-03-14 at 10:34:58 -0700, Russ Allbery wrote:
> Torsten Jerzembeck <to...@nightingale.ms.sub.org> writes:
> > The example provided in Appendix G of the DPM regarding the removal of
> > diversions doesn't work if the file diverted is a conffile. This is
> > due to the fact that conffiles are not removed during a "remove", but
> > but only during a "purge". As a "purge" implies a "remove" beforehand
> > (the postrm script is called twice), the example will fail even on a
> > "purge" with dpkg-divert refusing to clobber the existing conffile.
>
> > IMO a footnote should be added alerting the user to this fact and
> > providing a solution for this special case (use "purge" instead of
> > "remove" as the first test).
>
> The last time I looked at this (which was several years ago), diverting
> conffiles had enough problems that it was tempting to just say that it
> didn't work reliably. I wonder if we should explicitly recommend against
> diverting conffiles, or if some of those problems have been cleaned up.
> Some Debian sites, such as (IIRC) MIT, have extensive local infrastructure
> based on diverted conffiles and have run into all sorts of weird edge
> cases with them.

It should work way better than before, in part thanks the to the usage
and bug reporting from MIT, but as you say there's still some wrinkles,
which I plan on fixing for 1.17.x; in any case I'm always interested in
any bug reports affecting these.

There's for example still an unneeded prompt in one test case on the dpkg
functional test suite (t-conffile-divert-conffile):

<http://anonscm.debian.org/gitweb/?p=dpkg/pkg-tests.git;a=blob;f=Makefile;hb=HEAD>

Regarding this bug report, if there's anything to be updated that
should be either in the main policy or the dpkg documentation.

Thanks,
Guillem

[Torsten Jerzembeck]

Russ Allbery wrote:
>The last time I looked at this (which was several years ago), diverting
>conffiles had enough problems that it was tempting to just say that it
>didn't work reliably. I wonder if we should explicitly recommend against
>diverting conffiles, or if some of those problems have been cleaned up.

I've deployed the package I was building when I stumbled upon this in the
meantime and haven't met any problems. However, this is just a tiny
config package (it boils down to supplying some custom run.d snippets
for molly-guard and replacing /etc/molly-guard/rc with a customized
version).

>Some Debian sites, such as (IIRC) MIT, have extensive local infrastructure
>based on diverted conffiles and have run into all sorts of weird edge
>cases with them.

I've been using custom-build *-config packages for quite some time now,
as our current infrastructure makes this the easiest way to ship basic
configs to our systems (in fact it is nearly a no-brainer this way) and
have not run into problems until now (at least not that I'd remember).

This might be the first time I've had to divert an existing conffile,
however, As Adam pointed out, this usage seems to be in violation of
section 10.7.4 of the DPM, which I hadn't noticed. (Thanks for pointing
this out to me.) Perhaps a pointer to this section should be added to
Appendix G, to alert people arriving there via Google et al (like I
did)?

Greetings from Stuttgart,

=ToJe=

--
Torsten Jerzembeck * Oberschlesische Str. 61 * D-70374 Stuttgart
Exil-Westfale * PGP: B74DB58D * MIME welcome * Generation Tux * ><o(((°>

[Raphael Hertzog]

Hi,

On Thu, 14 Mar 2013, Guillem Jover wrote:
> It should work way better than before, in part thanks the to the usage
> and bug reporting from MIT, but as you say there's still some wrinkles,
> which I plan on fixing for 1.17.x; in any case I'm always interested in
> any bug reports affecting these.

The major issue I had with this case is when you try to purge the
diverting package. On remove, you put back in place in the original
conffile and at that point dpkg should (but doesn't currently) forget
about the conffile in the diverting package. Otherwise on purge, you
actually remove the diverted conffile and you have no files left.

I don't know if that's part of your "known wrinkles". If not, I'll happily
open a bug report. Let me know.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

[Charles Plessy]

Le Mon, Mar 18, 2013 at 08:59:01AM +0100, Raphael Hertzog a écrit :
>
> On Thu, 14 Mar 2013, Guillem Jover wrote:
> > It should work way better than before, in part thanks the to the usage
> > and bug reporting from MIT, but as you say there's still some wrinkles,
> > which I plan on fixing for 1.17.x; in any case I'm always interested in
> > any bug reports affecting these.
>
> The major issue I had with this case is when you try to purge the
> diverting package. On remove, you put back in place in the original
> conffile and at that point dpkg should (but doesn't currently) forget
> about the conffile in the diverting package. Otherwise on purge, you
> actually remove the diverted conffile and you have no files left.
>
> I don't know if that's part of your "known wrinkles". If not, I'll happily
> open a bug report. Let me know.

Hi all,

maybe a bug report would be a good way to track the issue and include a
reminder to update the Policy once it is solved ?

In the meantime, I propose to modify Appendix G by adding the following
sentence.

Do not attempt to divert a conffile, as <prog>dpkg</prog> does not handle
it well.

I know that we should not add contents to the appendices, but in that case it
already contains a similar warning about files vitally important for the
systemm, and I think that it would be confusing to separate the two warnings.

Cheers,

--
Charles Plessy
Tsurumi, Kanagawa, Japan

[Russ Allbery]

Charles Plessy <ple...@debian.org> writes:

> In the meantime, I propose to modify Appendix G by adding the following
> sentence.

> Do not attempt to divert a conffile, as <prog>dpkg</prog> does not handle
> it well.

> I know that we should not add contents to the appendices, but in that
> case it already contains a similar warning about files vitally important
> for the systemm, and I think that it would be confusing to separate the
> two warnings.

This sounds okay for the time being, although it sounds like we may be
able to drop some of those warnings before too long.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

[Charles Plessy]

Le Mon, Mar 25, 2013 at 09:22:08AM -0700, Russ Allbery a �crit :

> Charles Plessy <ple...@debian.org> writes:
>
> > In the meantime, I propose to modify Appendix G by adding the following
> > sentence.
>
> > Do not attempt to divert a conffile, as <prog>dpkg</prog> does not handle
> > it well.
>
> > I know that we should not add contents to the appendices, but in that
> > case it already contains a similar warning about files vitally important
> > for the systemm, and I think that it would be confusing to separate the
> > two warnings.
>
> This sounds okay for the time being, although it sounds like we may be
> able to drop some of those warnings before too long.

Thanks for the feedback.

I will commit this as a non-normative solution in the absence of comments in
the next few days.

Then, when dpkg will be corrected, we can remove this warning and the ones in
other sections.

Cheers,

--
Charles Plessy
Tsurumi, Kanagawa, Japan

[Charles Plessy]

tag 703022 pending
thanks

Le Tue, Mar 26, 2013 at 08:38:56AM +0900, Charles Plessy a �crit :

>
> I will commit this as a non-normative solution in the absence of comments in
> the next few days.

Comitted, thanks to everobody for your contribution.