[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#23712: conflicting packages with the same conffile



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/>



Reply to: