Debian Bug report logs - #163183
dpkg: Print when a package takes over a conffile from another removed package

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Christoph Martin <martin@verwaltung.uni-mainz.de>

To: submit@bugs.debian.org

Subject: dpkg: handling of registration of identical conffiles by different packages

Date: Mon, 24 May 1999 13:57:40 +0200

Package: dpkg
Version: 1.4.0.34

Francesco Potorti` writes:
 > Package: lynx-ssl
 > Version: 2.8.1-1
 > Severity: normal
 > 
 > I installed lynx-ssl, which removed lynx.  I then purged lynx, which
 > happily removed /etc/lynx.cfg, even if lynx-ssl was installed.
 > 

I investigated a little more here. It is a bug in the postinst of lynx
itself. 

If you install lynx /etc/lynx.cfg is listed as a conffile for lynx. If
you then remove it and install lynx-ssl, the same /etc/lynx.cfg is
listed as a conffile for lynx-ssl. Normally, if you now purge lynx,
dpkg would not remove lynx.cfg because it is no longer registered as a
conffile for lynx, but lynx has a special postrm which removes
lynx.cfg on purge anyway. This should not be.

I think there is also a bug in dpkg, because if different packages
register the same conffile, the last one will silently win and dpkg
will just overwrite the reference made my the first package.

Therefore I file a bug to dpkg

Christoph

-- System Information
Debian Release: 2.1
Kernel Version: Linux harriet 2.2.1 #1 SMP Thu Feb 25 17:48:56 MET 1999 i686 unknown

Versions of the packages dpkg depends on:
ii  libc6           2.0.7.19981211 GNU C Library: shared libraries
ii  libncurses4     4.2-3          Shared libraries for terminal handling
ii  libstdc++2.9    2.91.60-5      The GNU stdc++ library (egcs version)

Message #20 received at 38230@bugs.debian.org (full text, mbox, reply):

From: Thomas Hood <jdthood@yahoo.co.uk>

To: control@bugs.debian.org

Cc: 38230@bugs.debian.org, Christoph Martin <martin@verwaltung.uni-mainz.de>, Josip Rodin <joy@gkvk.hr>

Subject: unmerge 38230; reassign 38230 lynx

Date: 03 Oct 2002 11:01:19 +0200

unmerge 38230
reassign 38230 lynx
severity 38230 normal
thanks

The postrm of lynx and lynx-ssl should *not* rm -f
/etc/lynx.cfg .  The removal of conffiles should be left
to dpkg.

There may be a bug in dpkg too (see #109691), but it is independent
of this bug.

jdthood@thanatos:~$ dpkg -s lynx
Package: lynx
Status: install ok installed
Priority: standard
Section: web
Installed-Size: 3500
Maintainer: James Troup <james@nocrew.org>
Version: 2.8.4.1b-3
Provides: www-browser, news-reader
Depends: libc6 (>= 2.2.4-4), libncurses5 (>= 5.2.20010310-1), zlib1g (>=
1:1.1.3)
Recommends: mime-support
Conffiles:
 /etc/lynx.cfg d5deda8e0e06bb93bcce120c19a66e8f
[...]

jdthood@thanatos:/var/lib/dpkg/info$ cat lynx.postrm
#!/bin/sh

set -e

if [ -x /usr/bin/update-menus ]; then 
    update-menus
fi

if [ -x /usr/sbin/update-mime ]; then
    update-mime
fi

if [ "$1" = "purge" ]; then
    rm -f /etc/lynx.cfg
fi

[ Then I installed lynx-ssl ]

jdthood@thanatos:~$ dpkg -s lynx-ssl
Package: lynx-ssl
Status: install ok installed
Priority: extra
Section: non-US
Installed-Size: 3512
Maintainer: James Troup <james@nocrew.org>
Version: 1:2.8.4.1b-3
Provides: www-browser, news-reader, lynx
Depends: libc6 (>= 2.2.4-4), libncurses5 (>= 5.2.20010310-1),
libssl0.9.6, zlib1g (>= 1:1.1.3)
Recommends: mime-support
Conflicts: lynx
Conffiles:
 /etc/lynx.cfg d5deda8e0e06bb93bcce120c19a66e8f
[...]

jdthood@thanatos:~$ cat /var/lib/dpkg/info/lynx-ssl.postrm
#!/bin/sh

set -e

if [ -x /usr/bin/update-menus ]; then 
    update-menus
fi

if [ -x /usr/sbin/update-mime ]; then
    update-mime
fi

if [ "$1" = "purge" ]; then
    rm -f /etc/lynx.cfg
fi
--
Thomas Hood

Message #31 received at 38230@bugs.debian.org (full text, mbox, reply):

From: Thomas Hood <jdthood@yahoo.co.uk>

To: control@bugs.debian.org, 38230@bugs.debian.org

Cc: Christoph Martin <martin@verwaltung.uni-mainz.de>, Josip Rodin <joy@gkvk.hr>

Subject: clone 38230

Date: 03 Oct 2002 11:21:05 +0200

clone 38230 -1
retitle -1 Conflicting package should not silently stomp on conffiles
reassign -1 dpkg
severity -1 normal
thanks

38230 mentions another problem (so I'm cloning the report and
assigning the clone to dpkg):

> I think there is also a bug in dpkg, because if different packages
> register the same conffile, the last one will silently win and dpkg
> will just overwrite the reference made my the first package.

I agree that lynx-ssl should not *silently* replace lynx's
conffile with its own.  I am not sure that this behavior
satisfies policy either.

For convenient reference, policy 7.3 says:
------------------------------------------
When one binary package declares a conflict with another using a
Conflicts field, dpkg will refuse to allow them to be installed
 on the system at the same time.
 If one package is to be installed, the other must be removed first
 - if the package being installed is marked as replacing (see
Overwriting files and replacing packages - Replaces, Section 7.5)
 the one on the system, or the one on the system is marked as
 deselected, or both packages are marked Essential, then dpkg
 will automatically remove the package which is causing the
 conflict, otherwise it will halt the installation of the new
 package with an error. This mechanism is specifically designed
 to produce an error when the installed package is Essential,
 but the new package is not. 
A package will not cause a conflict merely because its configuration
 files are still installed; it must be at least half-installed.
A special exception is made for packages which declare a conflict with
 their own package name, or with a virtual package which they provide
 (see below): this does not prevent their installation, and allows a
 package to conflict with others providing a replacement for it. You
 use this feature when you want the package in question to be the only
 package providing some feature. 
------------------------------------------

jdthood@thanatos$ sudo apt-get install lynx-ssl
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
  lynx 
The following NEW packages will be installed:
  lynx-ssl 
0 packages upgraded, 1 newly installed, 1 to remove and 22  not
upgraded.
Need to get 1450kB of archives. After unpacking 12.3kB will be used.
Do you want to continue? [Y/n] 
Get:1 http://www.mirror.ac.uk woody/non-US/main lynx-ssl 1:2.8.4.1b-3
[1450kB]
Fetched 1450kB in 5m47s
(4170B/s)                                                               
dpkg: lynx: dependency problems, but removing anyway as you request:
 task-doc depends on lynx | links | w3m; however:
  Package lynx is to be removed.
  Package links is not installed.
  Package w3m is not installed.
(Reading database ... 107016 files and directories currently installed.)
Removing lynx ...
Selecting previously deselected package lynx-ssl.
(Reading database ... 106950 files and directories currently installed.)
Unpacking lynx-ssl (from .../lynx-ssl_1%3a2.8.4.1b-3_i386.deb) ...
Setting up lynx-ssl (2.8.4.1b-3) ...

--
Thomas

Message #44 received at 163183@bugs.debian.org (full text, mbox, reply):

From: Thomas Hood <jdthood@yahoo.co.uk>

To: Ben Collins <bcollins@debian.org>

Cc: 47267@bugs.debian.org, 163183@bugs.debian.org, Bill Gribble <grib@cs.utexas.edu>

Subject: Re: Bug #47267 in pam-apps?

Date: 03 Oct 2002 16:45:52 +0200

(This is information for #47267, but I am cc:ing #163183
since I make reference to it below.)

On Thu, 2002-10-03 at 15:23, Ben Collins wrote:
> On Thu, Oct 03, 2002 at 02:19:55PM +0200, Thomas Hood wrote:
> > I have a strong suspicion that the fault here lies with the
> > pam-apps package -- specifically, with its prerm or postrm.
> > Unfortunately, as pam-apps is obsolete and I can't find a copy
> > of the package anywhere, I can't confirm my suspicion.
> > 
> > The hypothesis is that the pam-apps postrm deleted /etc/pam.d/su
> > on remove or purge.  Other packages' postrms have been caught
> > doing the same (wrong) thing.
> 
> You're suspicion is incorrect.

How do you know?

> Most likely the case is that if pam-apps removed (not purged) and a
> newer login was installed that replaced /etc/pam.d/su, then latter
> pam-apps was "purged", removing the config files.

This does not happen.

I just tested your hypothesis on two packages that
share a conffile, the second Conflicts:ing with the
first (as login Conflicts: with pam-apps):
    1. Install #1 (which installs the conffile)
    2. Install #2 (which removes #1 and takes over the conffile)
    3. Purge #1
The last step did *not* delete the conffile.

It *is* a shortcoming of dpkg that at step 2, when the
second package is installed, the conffile is taken over
silently, *even if the conffile has been changed*,
without reporting anything or asking any questions.
This bug has been reported in #163183.

But dpkg does not seem to have the bug of deleting
conffiles that no longer belong to the package being purged.

I think this report should be closed, since the original
situation (involving pam-apps) can not be reproduced.

--
Thomas

Message #49 received at 163183@bugs.debian.org (full text, mbox, reply):

From: Ben Collins <bcollins@debian.org>

To: Thomas Hood <jdthood@yahoo.co.uk>

Cc: 47267@bugs.debian.org, 163183@bugs.debian.org, Bill Gribble <grib@cs.utexas.edu>

Subject: Re: Bug #47267 in pam-apps?

Date: Thu, 3 Oct 2002 10:48:50 -0400

> I just tested your hypothesis on two packages that
> share a conffile, the second Conflicts:ing with the
> first (as login Conflicts: with pam-apps):
>     1. Install #1 (which installs the conffile)
>     2. Install #2 (which removes #1 and takes over the conffile)
>     3. Purge #1
> The last step did *not* delete the conffile.

I said:

1. Install #1
2. Deinstall #2 (not purge)
3. Install #2
4. Purge #1

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Message #58 received at 163183@bugs.debian.org (full text, mbox, reply):

From: Adam Heath <doogie@debian.org>

To: Ben Collins <bcollins@debian.org>, <163183@bugs.debian.org>

Cc: Thomas Hood <jdthood@yahoo.co.uk>, <47267@bugs.debian.org>, Bill Gribble <grib@cs.utexas.edu>

Subject: Re: Bug#163183: Bug #47267 in pam-apps?

Date: Thu, 3 Oct 2002 11:28:21 -0500 (CDT)

On Thu, 3 Oct 2002, Ben Collins wrote:

> > I just tested your hypothesis on two packages that
> > share a conffile, the second Conflicts:ing with the
> > first (as login Conflicts: with pam-apps):
> >     1. Install #1 (which installs the conffile)
> >     2. Install #2 (which removes #1 and takes over the conffile)
> >     3. Purge #1
> > The last step did *not* delete the conffile.
>
> I said:
>
> 1. Install #1
> 2. Deinstall #2 (not purge)
> 3. Install #2
> 4. Purge #1

The above is the way I believe apt does things.

If this is the case, and the bug happens in Ben's version, but not Thomas',
then my guess is that all we need to do is add another simple test to a single
conditional.

Finding said conditional and which test to add is left as an excersize for
the reader.

Message #63 received at 163183-quiet@bugs.debian.org (full text, mbox, reply):

From: Thomas Hood <jdthood@yahoo.co.uk>

To: 163183-quiet@bugs.debian.org

Subject: the main issue

Date: 04 Oct 2002 12:09:48 +0200

163183 shouldn't have been cc:ed in some of those updates.

The issue in #163183 is (as the title says) that when dpkg
transfers a conffile from one package to another, it shouldn't
do so without reporting that it is doing so.  Furthermore, if
the conffile has been modified by the user then dpkg should
give the user the option to keep the old file or replace it
by the new one, as it does when it upgrades a package.

--
Thomas

Message #70 received at 163183@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Russ Allbery <rra@debian.org>, 23712@bugs.debian.org

Cc: 163183@bugs.debian.org

Subject: Re: Bug#23712: conflicting packages with the same conffile

Date: Thu, 19 Aug 2010 10:43:52 +0200

On Wed, 18 Aug 2010, Russ Allbery wrote:
> Yann Dirson <ydirson@mygale.org> writes:
> > Richard Braakman writes:
> 
> >> Yesterday I noticed that Debian policy is incorrect on this:
> 
> >>      Only packages that are tagged *conflicting* with each other may
> >>      specify the same file as `conffile'. A package may not modify a
> >>      configuration file of another package.
> 
> >> (section 3.3.7)
> 
> > Yes, this should be raised on deb-policy I think.
> 
> This is now 10.7.4, but the same issue is still there.  The concern is
> that conffiles remain even after the package is removed, so conflicts may
> be insufficiently strong and packages may simply never be able to use the
> same conffile as another package whether they declare conflicts or not.

I'm not sure that this is really the original concern. The initial report
wanted lintian to warn when two packages share the same conffile even if they
conflict... presumably because he thought that installing them would
result in an error. The fact that it does not might invalidate the report
entirely.

> What happens if you have a package on the system that's removed but not
> purged and you install another package (conflicting with the first) that
> contains the same conffile?  I suspect the conffile will be treated as
> locally modified and the newly installed package will get the conffile
> from the old removed package, but I'm not sure.

The conffile is taken over. The new version of the conffile is installed
and overwrites the previous one if it has not been modified (i.e. it
matches the md5sum recorded by the original package) otherwise you get the
usual prompt and the user decides which version is installed. This happens
with or without a Conflicts declaration.

We have a bug open against dpkg as well:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=163183

It mainly argues that dpkg should warn that the conffile is transferred
and that it should deal correctly with preserving user changes (which it
does nowadays apparently).

The fact that packages are marked as conflicting will just force apt to
remove it first, which means that the remaining conffille can then be
taken over even without a Replaces.

Given how little problem this behaviour has caused us, we might want as well
to document the current behaviour and make it policy rather than changing
a behaviour that has not been hurting us.

Anyone that wants to experiment with this can use the dpkg test-suite,
I have just added the corresponding tests:
http://git.debian.org/?p=dpkg/pkg-tests.git;a=commit;h=cb49886e1b1da2f86f6894eb3d754673b37380e0

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Message #75 received at 163183@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Raphael Hertzog <hertzog@debian.org>

Cc: 23712@bugs.debian.org, 163183@bugs.debian.org

Subject: Re: Bug#23712: conflicting packages with the same conffile

Date: Fri, 20 Aug 2010 15:36:16 -0700

Raphael Hertzog <hertzog@debian.org> writes:
> On Wed, 18 Aug 2010, Russ Allbery wrote:

>> What happens if you have a package on the system that's removed but not
>> purged and you install another package (conflicting with the first)
>> that contains the same conffile?  I suspect the conffile will be
>> treated as locally modified and the newly installed package will get
>> the conffile from the old removed package, but I'm not sure.

> The conffile is taken over. The new version of the conffile is installed
> and overwrites the previous one if it has not been modified (i.e. it
> matches the md5sum recorded by the original package) otherwise you get
> the usual prompt and the user decides which version is installed. This
> happens with or without a Conflicts declaration.

> We have a bug open against dpkg as well:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=163183

> It mainly argues that dpkg should warn that the conffile is transferred
> and that it should deal correctly with preserving user changes (which it
> does nowadays apparently).

> The fact that packages are marked as conflicting will just force apt to
> remove it first, which means that the remaining conffille can then be
> taken over even without a Replaces.

> Given how little problem this behaviour has caused us, we might want as
> well to document the current behaviour and make it policy rather than
> changing a behaviour that has not been hurting us.

I propose the following patch, which does two things.  First, it documents
this situation so that package maintainers with conflicting conffiles are
aware that they may see this.  Second, it reorders the section on sharing
configuration files to put all the sharing parts first and talk about
conflicts last, both to make the paragraph flow better and because I think
we want to encourage people to think about sharing rather than conflicting
as their first option.

Objections or seconds?

diff --git a/policy.sgml b/policy.sgml
index 9037de8..5fdf775 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7950,22 +7950,6 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
 	  <heading>Sharing configuration files</heading>
 
 	  <p>
-	    Packages which specify the same file as a
-	    <tt>conffile</tt> must be tagged as <em>conflicting</em>
-	    with each other.  (This is an instance of the general rule
-	    about not sharing files.  Note that neither alternatives
-	    nor diversions are likely to be appropriate in this case;
-	    in particular, <prgn>dpkg</prgn> does not handle diverted
-	    <tt>conffile</tt>s well.)
-	  </p>
-
-	  <p>
-	    The maintainer scripts must not alter a <tt>conffile</tt>
-	    of <em>any</em> package, including the one the scripts
-	    belong to.
-	  </p>
-
-	  <p>
 	    If two or more packages use the same configuration file
 	    and it is reasonable for both to be installed at the same
 	    time, one of these packages must be defined as
@@ -8014,6 +7998,34 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
 	    and which manages the shared configuration files.  (The
 	    <tt>sgml-base</tt> package is a good example.)
 	  </p>
+
+	  <p>
+	    If the configuration file cannot be shared as described above,
+	    the packages must be marked as conflicting with each other.
+	    Two packages that specify the same file as
+	    a <tt>conffile</tt> must conflict.  This is an instance of the
+	    general rule about not sharing files.  Neither alternatives
+	    nor diversions are likely to be appropriate in this case; in
+	    particular, <prgn>dpkg</prgn> does not handle diverted
+	    <tt>conffile</tt>s well.
+	  </p>
+
+	  <p>
+	    A package that declares the same <tt>conffile</tt> as another,
+	    conflicting package may see left-over configuration files from
+	    that other package.  If a user removes (without purging) one
+	    of the packages and installs the other, the new package will
+	    take over the <tt>conffile</tt> from the old package.  If the
+	    file was modified by the user, it will be treated the same as
+	    any other locally modified <tt>conffile</tt> during an
+	    upgrade.
+	  </p>
+
+	  <p>
+	    The maintainer scripts must not alter a <tt>conffile</tt>
+	    of <em>any</em> package, including the one the scripts
+	    belong to.
+	  </p>
 	</sect1>
 
 	<sect1>

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

Message #80 received at 163183@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Russ Allbery <rra@debian.org>, 23712@bugs.debian.org

Cc: 163183@bugs.debian.org

Subject: Re: Bug#23712: conflicting packages with the same conffile

Date: Sat, 21 Aug 2010 08:35:01 +0200

On Fri, 20 Aug 2010, Russ Allbery wrote:
> Objections or seconds?

Looks mostly good except:

> @@ -8014,6 +7998,34 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
>  	    and which manages the shared configuration files.  (The
>  	    <tt>sgml-base</tt> package is a good example.)
>  	  </p>
> +
> +	  <p>
> +	    If the configuration file cannot be shared as described above,
> +	    the packages must be marked as conflicting with each other.
> +	    Two packages that specify the same file as
> +	    a <tt>conffile</tt> must conflict.  This is an instance of the
> +	    general rule about not sharing files.  Neither alternatives
> +	    nor diversions are likely to be appropriate in this case; in
> +	    particular, <prgn>dpkg</prgn> does not handle diverted
> +	    <tt>conffile</tt>s well.
> +	  </p>
> +
> +	  <p>
> +	    A package that declares the same <tt>conffile</tt> as another,
> +	    conflicting package may see left-over configuration files from
> +	    that other package.

EPARSE on this sentence, it looks like some words are missing.

>  If a user removes (without purging) one
> +	    of the packages and installs the other, the new package will
> +	    take over the <tt>conffile</tt> from the old package.  If the
> +	    file was modified by the user, it will be treated the same as
> +	    any other locally modified <tt>conffile</tt> during an
> +	    upgrade.
> +	  </p>
> +
> +	  <p>
> +	    The maintainer scripts must not alter a <tt>conffile</tt>
> +	    of <em>any</em> package, including the one the scripts
> +	    belong to.
> +	  </p>

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Message #85 received at 163183@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Raphael Hertzog <hertzog@debian.org>

Cc: 23712@bugs.debian.org, 163183@bugs.debian.org

Subject: Re: Bug#23712: conflicting packages with the same conffile

Date: Sat, 21 Aug 2010 01:23:25 -0700

Raphael Hertzog <hertzog@debian.org> writes:
> On Fri, 20 Aug 2010, Russ Allbery wrote:

>> +	  <p>
>> +	    A package that declares the same <tt>conffile</tt> as another,
>> +	    conflicting package may see left-over configuration files from
>> +	    that other package.

> EPARSE on this sentence, it looks like some words are missing.

Hm.  All the words that I had intended to be there are there.  I clearly
need to rephrase it somehow, though, if it's not clear.  How about:

    When two packages both declare the same <tt>conffile</tt>, they may
    see left-over configuration files from each other even though they
    conflict with each other.

>>  If a user removes (without purging) one
>> +	    of the packages and installs the other, the new package will
>> +	    take over the <tt>conffile</tt> from the old package.  If the
>> +	    file was modified by the user, it will be treated the same as
>> +	    any other locally modified <tt>conffile</tt> during an
>> +	    upgrade.
>> +	  </p>

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

Message #90 received at 163183@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Russ Allbery <rra@debian.org>, 163183@bugs.debian.org

Cc: 23712@bugs.debian.org

Subject: Re: Bug#163183: Bug#23712: conflicting packages with the same conffile

Date: Sat, 21 Aug 2010 16:47:10 +0200

On Sat, 21 Aug 2010, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
> > On Fri, 20 Aug 2010, Russ Allbery wrote:
> 
> >> +	  <p>
> >> +	    A package that declares the same <tt>conffile</tt> as another,
> >> +	    conflicting package may see left-over configuration files from
> >> +	    that other package.
> 
> > EPARSE on this sentence, it looks like some words are missing.
> 
> Hm.  All the words that I had intended to be there are there.  I clearly
> need to rephrase it somehow, though, if it's not clear.  How about:
> 
>     When two packages both declare the same <tt>conffile</tt>, they may
>     see left-over configuration files from each other even though they
>     conflict with each other.

I was confused by the comma. I supposed it was meant to split the whole
sentence...

But the second wording is better IMO.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Message #95 received at 163183@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Russ Allbery <rra@debian.org>, 23712@bugs.debian.org

Cc: Raphael Hertzog <hertzog@debian.org>, 163183@bugs.debian.org

Subject: Re: Bug#23712: conflicting packages with the same conffile

Date: Fri, 8 Oct 2010 21:50:30 +0200

[Message part 1 (text/plain, inline)]

Russ Allbery <rra@debian.org> (20/08/2010):
> Objections or seconds?

Seconded. Both this version and the other, reworded version.

Mraw,
KiBi.

> diff --git a/policy.sgml b/policy.sgml
> index 9037de8..5fdf775 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -7950,22 +7950,6 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
>  	  <heading>Sharing configuration files</heading>
>  
>  	  <p>
> -	    Packages which specify the same file as a
> -	    <tt>conffile</tt> must be tagged as <em>conflicting</em>
> -	    with each other.  (This is an instance of the general rule
> -	    about not sharing files.  Note that neither alternatives
> -	    nor diversions are likely to be appropriate in this case;
> -	    in particular, <prgn>dpkg</prgn> does not handle diverted
> -	    <tt>conffile</tt>s well.)
> -	  </p>
> -
> -	  <p>
> -	    The maintainer scripts must not alter a <tt>conffile</tt>
> -	    of <em>any</em> package, including the one the scripts
> -	    belong to.
> -	  </p>
> -
> -	  <p>
>  	    If two or more packages use the same configuration file
>  	    and it is reasonable for both to be installed at the same
>  	    time, one of these packages must be defined as
> @@ -8014,6 +7998,34 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
>  	    and which manages the shared configuration files.  (The
>  	    <tt>sgml-base</tt> package is a good example.)
>  	  </p>
> +
> +	  <p>
> +	    If the configuration file cannot be shared as described above,
> +	    the packages must be marked as conflicting with each other.
> +	    Two packages that specify the same file as
> +	    a <tt>conffile</tt> must conflict.  This is an instance of the
> +	    general rule about not sharing files.  Neither alternatives
> +	    nor diversions are likely to be appropriate in this case; in
> +	    particular, <prgn>dpkg</prgn> does not handle diverted
> +	    <tt>conffile</tt>s well.
> +	  </p>
> +
> +	  <p>
> +	    A package that declares the same <tt>conffile</tt> as another,
> +	    conflicting package may see left-over configuration files from
> +	    that other package.  If a user removes (without purging) one
> +	    of the packages and installs the other, the new package will
> +	    take over the <tt>conffile</tt> from the old package.  If the
> +	    file was modified by the user, it will be treated the same as
> +	    any other locally modified <tt>conffile</tt> during an
> +	    upgrade.
> +	  </p>
> +
> +	  <p>
> +	    The maintainer scripts must not alter a <tt>conffile</tt>
> +	    of <em>any</em> package, including the one the scripts
> +	    belong to.
> +	  </p>
>  	</sect1>
>  
>  	<sect1>

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.