Debian Bug report logs - #146167
[CONFFILE] Add way to purge package but keep conffiles?

Display info messages

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

From: Andrew Ferrier <andrew@new-destiny.co.uk>

To: Debian Bug Tracking System <maintonly@bugs.debian.org>

Subject: apt: No way to purge record of package without purging config files

Date: Tue, 07 May 2002 16:05:47 +0100

Package: apt
Version: 0.5.4
Severity: wishlist

It would very useful if apt had a facility to purge packages _from the database_ without
purging the config files for the package. For example, I have installed exim-tls, which
shares config files with exim. I now have exim-tls working and have removed exim, but not
purged it, because if I purge it, then it will delete the config files for exim-tls (since
they are the same ones).

Perhaps a --databaseonly option so that this idea could be used with remove too? (removing
packages from the database without removing the binaries/docs etc.) Obviously this option
would never be turned on by default and a warning would be placed in the documentation
against abusing it.

Alternatively, how about an auto-detect so that config files are not purged if they are
shared? (such as in the case above)

Andrew Ferrier

email: andrew@new-destiny.co.uk
web: http://www.new-destiny.co.uk/andrew/

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux laura 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686
Locale: LANG=C, LC_CTYPE=

Versions of packages apt depends on:
ii  libc6                         2.2.5-4    GNU C Library: Shared libraries an
ii  libstdc++2.10-glibc2.2        1:2.95.4-7 The GNU stdc++ library

Message #10 received at 146167-maintonly@bugs.debian.org (full text, mbox, reply):

From: Randolph Chung <tausq@debian.org>

To: Andrew Ferrier <andrew@new-destiny.co.uk>, 146167-maintonly@bugs.debian.org

Subject: Re: Bug#146167: apt: No way to purge record of package without purging config files

Date: Tue, 7 May 2002 11:04:16 -0700

> It would very useful if apt had a facility to purge packages _from the database_ without
> purging the config files for the package. For example, I have installed exim-tls, which
> shares config files with exim. I now have exim-tls working and have removed exim, but not
> purged it, because if I purge it, then it will delete the config files for exim-tls (since
> they are the same ones).

eh? apt-get doesn't do a purge by default, it only does remove. 

randolph 

Message #15 received at 146167-maintonly@bugs.debian.org (full text, mbox, reply):

From: Andrew Ferrier <ajf98@doc.ic.ac.uk>

To: Randolph Chung <tausq@debian.org>

Cc: 146167-maintonly@bugs.debian.org

Subject: Re: Bug#146167: apt: No way to purge record of package without purging config files

Date: Tue, 7 May 2002 18:14:06 +0100 (BST)

On 2002-05-07 at 11:04, Randolph Chung wrote:

> > It would very useful if apt had a facility to purge
> > packages _from the database_ without purging the config
> > files for the package. For example, I have installed
> > exim-tls, which shares config files with exim. I now have
> > exim-tls working and have removed exim, but not purged it,
> > because if I purge it, then it will delete the config files
> > for exim-tls (since they are the same ones).
>
> eh? apt-get doesn't do a purge by default, it only does remove.

Randolph,

I realise that. That wasn't the feature I was describing. The
problem arises when two packages share the same config files
(e.g. exim and exim-tls): with both installed, it is impossible
to purge one and remove it from the dpkg database entirely
without removing the config files for the other (because they
are the same config files). I was suggesting an option to purge
from the dpkg database WITHOUT deleting the config files.

-- 
Andrew Ferrier

web:           http://www.new-destiny.co.uk/andrew/
email:         andrew@new-destiny.co.uk

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

From: Adam Heath <doogie@debian.org>

To: Andrew Ferrier <ajf98@doc.ic.ac.uk>, <146167@bugs.debian.org>

Subject: Re: Bug#146167: apt: No way to purge record of package without purging config files

Date: Tue, 7 May 2002 12:38:30 -0500 (CDT)

reassign 146167 dpkg
thanks

> I realise that. That wasn't the feature I was describing. The
> problem arises when two packages share the same config files
> (e.g. exim and exim-tls): with both installed, it is impossible
> to purge one and remove it from the dpkg database entirely
> without removing the config files for the other (because they
> are the same config files). I was suggesting an option to purge
> from the dpkg database WITHOUT deleting the config files.

This is a dpkg problem.  I suggest you deal with it there, not for apt.

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

From: Anthony Towns <aj@azure.humbug.org.au>

To: Adam Heath <doogie@debian.org>, 146167@bugs.debian.org

Cc: Andrew Ferrier <ajf98@doc.ic.ac.uk>

Subject: Re: Bug#146167: apt: No way to purge record of package without purging config files

Date: Fri, 10 May 2002 04:49:25 +1000

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

On Tue, May 07, 2002 at 12:38:30PM -0500, Adam Heath wrote:
> > I realise that. That wasn't the feature I was describing. The
> > problem arises when two packages share the same config files
> > (e.g. exim and exim-tls): with both installed, it is impossible
> > to purge one and remove it from the dpkg database entirely
> > without removing the config files for the other (because they
> > are the same config files). 
> This is a dpkg problem.  I suggest you deal with it there, not for apt.

That's nifty. Policy says:

] 11.7.4. Sharing configuration files
] -----------------------------------
]      Packages which specify the same file as a `conffile' must be tagged
]      as _conflicting_ with each other. 

...but clearly that's not actually enough, since conflicts aren't taken into
account when a package is removed-but-not-purged.

Perhaps if you have a conffile <foo> mentioned by removed-but-not-purged
package <bar>, and also by newly-installed-package <baz> ownership of the
conffile should be automatically transferred to <baz> (and possibly <bar>
should "disappear" if appropriate)?

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

     ``BAM! Science triumphs again!'' 
                    -- http://www.angryflower.com/vegeta.gif

[Message part 2 (application/pgp-signature, inline)]

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

From: Andrew Ferrier <ajf98@doc.ic.ac.uk>

To: Anthony Towns <aj@azure.humbug.org.au>

Cc: Adam Heath <doogie@debian.org>, <146167@bugs.debian.org>

Subject: Re: Bug#146167: apt: No way to purge record of package without purging config files

Date: Fri, 10 May 2002 11:37:55 +0100 (BST)

On 2002-05-10 at 04:49, Anthony Towns wrote:

> > > I realise that. That wasn't the feature I was describing. The
> > > problem arises when two packages share the same config files
> > > (e.g. exim and exim-tls): with both installed, it is impossible
> > > to purge one and remove it from the dpkg database entirely
> > > without removing the config files for the other (because they
> > > are the same config files).
> > This is a dpkg problem.  I suggest you deal with it there, not for apt.
>
> That's nifty. Policy says:
>
> ] 11.7.4. Sharing configuration files
> ] -----------------------------------
> ]      Packages which specify the same file as a `conffile' must be tagged
> ]      as _conflicting_ with each other.
>
> ...but clearly that's not actually enough, since conflicts aren't taken into
> account when a package is removed-but-not-purged.
>
> Perhaps if you have a conffile <foo> mentioned by removed-but-not-purged
> package <bar>, and also by newly-installed-package <baz> ownership of the
> conffile should be automatically transferred to <baz> (and possibly <bar>
> should "disappear" if appropriate)?

Yes, that would be ideal solution I think because it would
ensure that dpkg is responsible for keeping it's database
consistent --- obviously it wouldn't do what you've just
suggested (i.e. automagically purge a package from the
database) unless another package owned the same config. files.

But another solution, which would probably be easier to
implement, if not as neat, would be simply to provide the user
of dpkg an option to force removal/purging from the database
without deleting the config. files.

Don't know which one the dpkg developers prefer the sound of
but I hope you agree this is a problem --- I think it is (if
purely just one of neatness of the database!)

-- 
Andrew Ferrier

web:           http://www.new-destiny.co.uk/andrew/
email:         andrew@new-destiny.co.uk

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

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

To: 146167-quiet@bugs.debian.org

Cc: Anthony Towns <aj@azure.humbug.org.au>, Andrew Ferrier <andrew@new-destiny.co.uk>

Subject: Re: #146167

Date: 07 Oct 2002 14:39:39 +0200

Anthony Towns wrote:
> Perhaps if you have a conffile <foo> mentioned by
> removed-but-not-purged package <bar>, and also by
> newly-installed-package <baz>, ownership of the
> conffile should be automatically transferred to <baz>
> (and possibly <bar> should "disappear" if appropriate)?

Isn't this what dpkg already does (or is supposed to do,
barring bugs like #129697)?

This is actually a side-issue so far as report #146167
is concerned.  This report is a wish for a command that
would eliminate dpkg's knowledge of a package without
actually purging the package.  Presumably this sort of
kludgery can be done with rm, vi and the status file?

--
Thomas

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

From: Andrew Ferrier <andrew@new-destiny.co.uk>

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

Cc: 146167-quiet@bugs.debian.org, Anthony Towns <aj@azure.humbug.org.au>

Subject: Re: #146167

Date: Mon, 7 Oct 2002 21:38:07 +0100 (BST)

On 2002-10-07 at 14:39 +0200, Thomas Hood wrote:

> Anthony Towns wrote:
> > Perhaps if you have a conffile <foo> mentioned by
> > removed-but-not-purged package <bar>, and also by
> > newly-installed-package <baz>, ownership of the
> > conffile should be automatically transferred to <baz>
> > (and possibly <bar> should "disappear" if appropriate)?
>
> Isn't this what dpkg already does (or is supposed to do,
> barring bugs like #129697)?

Maybe it's supposed to, but I've never seen it behave like
that. To pick the example I used to start off this bug report,
migrating from exim to exim-tls, keeping the same config.
files, is tricky with dpkg, because it seems to consider (at
least dpkg -L indicates) that config. files belong to both
packages, even if I have removed (not purged) exim. As soon as
I purge exim, who knows what will happen? Certainly I wouldn't
have the confidence to do it.

> This is actually a side-issue so far as report #146167 is
> concerned.  This report is a wish for a command that would
> eliminate dpkg's knowledge of a package without actually
> purging the package.  Presumably this sort of kludgery can be
> done with rm, vi and the status file?

OK, as the original bug submitter <grin>:

1. Not it's not a side-issue. The command is requested as a
potential solution to the problem I described above, not
because I think the command would be helpful in itself. The
command in itself is not the request.

2. Yes the kludgery could be done like that. But that's not a
good solution to the problem I describe above (migrating from
exim to exim-tls), for example.

Regards,
Andrew.

-- 
Andrew Ferrier

mobile:  +44 (0) 7968 147953
web:     http://www.new-destiny.co.uk/andrew/
email:   andrew@new-destiny.co.uk

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

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

To: 146167-quiet@bugs.debian.org

Subject: retitle and merge

Date: Thu, 11 Mar 2004 14:19:38 +0100

retitle 146167 [CONFFILE] Add way to purge package but keep conffiles?
severity 146167 important
merge 146167 47267
thanks

This is intended as a workaround for #47267 et al.

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

From: Scott James Remnant <scott@netsplit.com>

To: debian-dpkg@lists.debian.org, debian-bugs-dist@lists.debian.org, 10879-quiet@bugs.debian.org, 33046-quiet@bugs.debian.org, 47267-quiet@bugs.debian.org, 90623-quiet@bugs.debian.org, 98210-quiet@bugs.debian.org, 109691-quiet@bugs.debian.org, 146167-quiet@bugs.debian.org, 155456-quiet@bugs.debian.org, 204275-quiet@bugs.debian.org

Cc: rjk@greenend.org.uk, Cesar Eduardo Barros <cesarb@nitnet.com.br>, Bill Gribble <grib@cs.utexas.edu>, Gabor FLEISCHER <flocsy@mail.mtesz.hu>, Matthew Swift <swift@alum.mit.edu>, Richard A Nelson <cowboy@vnet.ibm.com>, Andrew Ferrier <andrew@new-destiny.co.uk>, Karl Erik <oyoy@oyoy.org>, Vincent Lefevre <vincent@vinc17.org>, Bdale Garbee <bdale@gag.com>, Thomas Hood <jdthood@yahoo.co.uk>, Randolph Chung <tausq@debian.org>, Anthony Towns <aj@azure.humbug.org.au>, Colin Watson <cjwatson@debian.org>, Eneko Lacunza <enlar@endymion.enlar.net>

Subject: dpkg removes conffiles when purging a package that no longer owns them

Date: Fri, 12 Mar 2004 20:26:23 +0000

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

tags 10879 patch pending
thanks

There's quite a few people on this list, so I'll start out by saying
that if you don't care about this bug anymore, or are just glad I think
I've fixed it, then you don't really need to read this mail.  There's a
patch at the bottom, the rest is going to be pretty technical :-)


First a summary of this bug, picking on bind as it's a handy package
that can be used to reliably produce the symptoms.

 1. Install bind
 2. Install bind9, this will remove bind.
 3. Purge bind

You'll now find that a random selection of bind9's configuration files
have been removed.


The clue to solving this bug occurred when we realised that the
selection wasn't random at all, and in fact was the same on every
machine.

Here's the important bit of debug output concerning the purging of bind:

D000200: removal_bulk set to new conffile `/etc/init.d/bind'
D000020: removal_bulk conffile not ours any more `/etc/bind/named.conf'
D000020: removal_bulk conffile not ours any more `/etc/bind/named.conf.local'
D000020: removal_bulk conffile not ours any more `/etc/bind/named.conf.options'
D000020: removal_bulk conffile not ours any more `/etc/bind/db.0'
D000020: removal_bulk conffile not ours any more `/etc/bind/db.127'
D000020: removal_bulk conffile not ours any more `/etc/bind/db.255'
D000020: removal_bulk conffile not ours any more `/etc/bind/db.local'
D000020: removal_bulk conffile not ours any more `/etc/bind/db.root'

dpkg is correctly realising that the only conffile it needs to remove is
‘/etc/init.d/bind’ and that the rest should be kept because bind9 has
taken them over.

However it's removing some of them, and fortunately the ones it removes
is constant.  It removes ‘named.conf.local’, ‘db.0’, ‘db.255’ and
‘db.root’.

If we number the configuration files that it shouldn't remove, starting
at 1, it's removing #2, #4, #6 and #8.


That's a pretty damned specific pattern!  It also explains why the
single-conffile test package pairs don't exhibit the bug, if they had
two conffiles the second would get wrongly deleted.

A more extreme example (a test package I created):

 #1 should be kept
 #2 needs deleting
 #3 should be kept
 #4 should be kept
 #5 needs deleting

#4 gets incorrectly deleted by dpkg.

To put the problem into words; every second conffile in a consecutive
subset that need to be kept get incorrectly deleted.


Old C hands should already be thinking ‘linked list bug’ at this point.


We now cast our attention on the removal_bulk_remove_configfiles()
function in main/remove.c.  What it does can be summed up as follows:

 1. Iterate the conffiles list, removing nodes if the conffile isn't
    ours anymore or is part of a diversion.

 2. Iterate the conffiles list again (which will have the nodes removed)
    and do the actual work.


Reading the debug output, during the second iteration there are nodes
that were supposed to have been removed that weren't.  We're really
thinking ‘linked list bug’ at this point, almost certainly a classic
‘bad node removal’ problem.

So we focus our attention on the first loop, and walk through it.  I'm
going to assume you've got the code in front of you at this point, feel
free to grab it if you're interested.

Our players in this are:

pkg->installed.conffiles
	A pointer to the first node in a linked list of conffile
	structures.  Each structure has a ‘next’ pointer which either
	points to the next one in the list, or NULL.

lconffp
	At the start of the loop, this points to the linked list pointer
	itself (pkg->installed.conffiles), otherwise it points to the
	‘next’ member of the previous node.

conff
	A pointer to a node.  This is set at the start of each iteration
	to the contents of whatever lconffp points to, so the first node
	for the first iteration, and each subsequent node.


Let's go back to using bind/bind9 as our example pair, because that's
quite an elegant example.

The first conffile needs to be deleted, so nothing interesting happens
until the loop's step statement:

	lconffp= &conff->next;

This alters lconffp to point to the current node's ‘next’ pointer, and
when the list begins, conff will point at the next node.


The second conffile needs to be kept, so the node needs to be removed
from the linked list.  Here's the code that does that:

	*lconffp= conff->next;

This alters either the linked list pointer, or the previous node's
‘next’ pointer (which is pointed to by lconffp) to point to the next
node, not the current one.  In other words, it removes the current node
from the linked list.

Now we get to the step instruction:

	lconffp= &conff->next;

This alters lconffp to point to the current node's ‘next‘ pointer. 
Hopefully your brain just threw an exception there.  That's right,
lconffp is now pointing to *the wrong thing*; if the next node needs to
be removed as well, the ‘next’ pointer of a node that's been removed
from the linked list will be changed.

We start off with:

	[  |--->[  |--->[  |x]
	   ^     ^
	[**]	[--]

([**] is lconffp, [--] is conff)

We alter the pointer to remove the node:

	[  |----------->[  |x]
	   ^    [  |--->
	   |     ^
	[**]    [--]

Then we end up pointing at the wrong next node:

	[  |----------->[  |x]
	        [  |---> ^
	           ^     |
	        [**]    [--]

If we need to remove the next node as well, we'll end up altering the
wrong pointer:

	[  |----------->[  |x]
	        [  |x]
	           ^
	        [**]    [--]

In fact, we didn't need to move lconffp at all.  If we remove a node,
the linked list pointer itself or the previous ‘next’ pointer is still
the previous node pointer.

In other words, we only need to run the step statement if we don't
remove the node.  If we modify the code to do that, and run that
simulation again:

We start off with:

	[  |--->[  |--->[  |x]
	   ^     ^
	[**]	[--]

([**] is lconffp, [--] is conff)

We alter the pointer to remove the node:

	[  |----------->[  |x]
	   ^    [  |--->
	   |     ^
	[**]    [--]

And we begin the new iteration of the loop with no step condition:

	[  |----------->[  |x]
	   ^    [  |---> ^
	   |             |
	[**]            [--]

The removed node has now become irrelevant.  First let's simulate
removing the next node, as that's what's failing.  We alter the pointer
to remove the node:

	[  |x]          [  |x]
	   ^             
	[**]    [--]

That's done the right thing, both nodes have been removed.  Now let's
assume that node needed keeping.  We don't alter the pointer to remove
the node, instead we *do* run the loop's step condition:

	[  |----------->[  |x]
	                   ^
	                [**]    [--]

This correctly removes the second node, but keeps the third in the
list.  If the next node was to be removed, the right pointer would be
modified.


So in summary, what was causing this bug was some incorrect code to
remove nodes from a linked list.  The step condition caused a pointer to
be moved that should've been kept where it was.  By only running this
step condition when we haven't removed a node, the right pointers are
modified and the list can be traversed properly the second time around.

Patch attached and committed.


I'm a little nervous about trying to push this change for sarge without
some extensive testing.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

[dpkg-conffile-list.patch (text/x-patch, inline)]

Index: ChangeLog
===================================================================
--- ChangeLog	(revision 1897)
+++ ChangeLog	(working copy)
@@ -1,3 +1,13 @@
+Fri Mar 12 19:02:21 GMT 2004 Scott James Remnant <scott@netsplit.com>
+
+  * main/remove.c (removal_bulk_remove_configfiles): Don't change the
+  "previous pointer" pointer if we remove the node from the linked list,
+  ensuring that if the next node is to be removed the right thing will
+  happen.
+
+  This corrects the bug where every second shared or diverted conffile
+  would be incorrectly deleted by dpkg.
+ 
 Fri Mar 12 15:05:52 GMT 2004 Scott James Remnant <scott@netsplit.com>
 
   * utils/start-stop-daemon.c: Don't require an argument for -V (version).
Index: debian/changelog
===================================================================
--- debian/changelog	(revision 1897)
+++ debian/changelog	(working copy)
@@ -1,6 +1,10 @@
 dpkg (1.10.21) unstable; urgency=low
 
   * Don't require argument for start-stop-daemon -V.  Closes: #237589.
+  * Fix incorrect linked list node removal code that caused every second
+    shared or diverted conffile to be deleted by dpkg.
+    Closes: #10879, #33046, #47267, #90623, #98210, #109691, #146167.
+    Closes: #155456, #204275.
 
  -- Scott James Remnant <scott@netsplit.com>  UNRELEASED
 
Index: main/remove.c
===================================================================
--- main/remove.c	(revision 1891)
+++ main/remove.c	(working copy)
@@ -403,9 +403,7 @@
      * are involved in diversions, except if we are the package doing the
      * diverting.
      */
-    for (lconffp= &pkg->installed.conffiles;
-         (conff= *lconffp) != 0;
-         lconffp= &conff->next) {
+    for (lconffp= &pkg->installed.conffiles; (conff= *lconffp) != 0; ) {
       for (searchfile= pkg->clientdata->files;
            searchfile && strcmp(searchfile->namenode->name,conff->name);
            searchfile= searchfile->next);
@@ -422,6 +420,7 @@
       } else {
         debug(dbg_conffdetail,"removal_bulk set to new conffile `%s'",conff->name);
         conff->hash= NEWCONFFILEFLAG; /* yes, cast away const */
+        lconffp= &conff->next;
       }
     }
     modstatdb_note(pkg);

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

Message #69 received at 10879-close@bugs.debian.org (full text, mbox, reply):

From: Scott James Remnant <scott@netsplit.com>

To: 10879-close@bugs.debian.org

Subject: Bug#10879: fixed in dpkg 1.10.21

Date: Sun, 25 Apr 2004 14:17:03 -0400

Source: dpkg
Source-Version: 1.10.21

We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive:

dpkg-dev_1.10.21_all.deb
  to pool/main/d/dpkg/dpkg-dev_1.10.21_all.deb
dpkg-doc_1.10.21_all.deb
  to pool/main/d/dpkg/dpkg-doc_1.10.21_all.deb
dpkg_1.10.21.dsc
  to pool/main/d/dpkg/dpkg_1.10.21.dsc
dpkg_1.10.21.tar.gz
  to pool/main/d/dpkg/dpkg_1.10.21.tar.gz
dpkg_1.10.21_i386.deb
  to pool/main/d/dpkg/dpkg_1.10.21_i386.deb
dselect_1.10.21_i386.deb
  to pool/main/d/dpkg/dselect_1.10.21_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 10879@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Scott James Remnant <scott@netsplit.com> (supplier of updated dpkg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 25 Apr 2004 18:55:10 +0100
Source: dpkg
Binary: dpkg-doc dpkg dselect dpkg-dev dpkg-static
Architecture: source all i386
Version: 1.10.21
Distribution: unstable
Urgency: low
Maintainer: Dpkg Development <debian-dpkg@lists.debian.org>
Changed-By: Scott James Remnant <scott@netsplit.com>
Description: 
 dpkg       - Package maintenance system for Debian
 dpkg-dev   - Package building tools for Debian
 dpkg-doc   - Dpkg Internals Documentation
 dselect    - a user tool to manage Debian packages
Closes: 10879 33046 47267 90623 98210 102094 109669 109691 115352 120970 124225 146167 151799 155456 158916 160761 161156 166052 171489 174973 174978 179192 187952 200701 200763 204275 207758 214699 219210 220776 225086 233614 237589 237624 237864 239000 240081 241503 242870 243191 244098 244316
Changes: 
 dpkg (1.10.21) unstable; urgency=low
 .
   * Fix incorrect linked list node removal code that caused every second
     shared or diverted conffile to be deleted by dpkg.
     Closes: #10879, #33046, #47267, #90623, #98210, #109691, #146167.
     Closes: #155456, #204275.
   * Call mknod with the required device type.  Closes: #158916.
   * Correct the default query output format to be consistent with
     what the underlying library expects.  Closes: #174973.
   * Fix missing NULL-termination in dpkg-query -W display of dependency
     fields.  Closes: #174978
   * Strip output from md5sum(1) after the first whitespace character.
     Closes: #200763.
   * Output a warning if we cannot open a configuration file instead of
     treating it as a fatal error, in case our home directory is not readable
     by root.  Closes: #200701.
   * Set LC_ALL to C before spawning off dpkg --search, to avoid searching
     on localized strings.  Closes: #244316.
   * Don't require argument for start-stop-daemon -V.  Closes: #237589.
   * Correct use of @ARGV within dpkg-scanpackages, allowing -u to work
     once again.  Closes: #225086, #241503.
   * Make sure file permissions passed to dpkg-statoverride are numeric.
     Closes: #161156.
   * Correctly break out of the loop in install-info.
     Closes: #124225, #160761.
   * Add --dir-file option to install-info for GNU install-info
     compatibility.  Closes: #179192
   * Refer to debian-policy in dpkg-doc's description instead of the
     non-existant packaging-manual.  Closes: #120970.
   * Remove incorrect mention of build-essential from dpkg-checkbuilddeps
     manpage.  Closes: #219210.
   * Add a note about diverting shared libraries to the dpkg-divert
     manpage.  Closes: #214699.
   * Updated Translations:
     - Brazilian Portugese (Andre Luis Lopes).  Closes: #237864.
     - Catalan (Jordi Mallach).
     - Danish (Claus Hindsgaul).  Closes: #237624.
     - Dutch (Pieter-Paul Spiertz, Bart Cornelis, Erwin).
       Closes: #102094, #151799, #207758.
     - French (Sam Hocevar).  Closes: #243191.
     - German (Florian Ernst).  Closes: #109669, #115352, #187952, #244098.
     - Japanese manpages (KISE Hiroshi).  Closes: #220776.
     - Polish (Bartosz Fenski).  Closes: #242870.
     - Spanish (Javier Fernández-Sanguino Peña).  Closes: #166052.
     - Swedish (Peter Karlsson).
   * New Translations:
     - Japanese dpkg-source manpage (KISE Hiroshi).  Closes: #239000.
     - Norwegian Nynorsk (Gaute Hvoslef Kvalnes).  Closes: #233614.
     - Portguese (Miguel Figueiredo).  Closes: #240081.
     - Spanish dpkg-source manpage (Ruben Porras).  Closes: #171489.
Files: 
 3c0ee1d26bd55362b92eee8e6255aee0 798 base required dpkg_1.10.21.dsc
 a9f6c43891db74d727beab7dfc0ee663 1682647 base required dpkg_1.10.21.tar.gz
 e492251ba4cf345982782b7880056e1f 1220962 base required dpkg_1.10.21_i386.deb
 132ac9df0f3dd8fd8b7adbf409f8ed3e 105530 base required dselect_1.10.21_i386.deb
 48e0a00caea19997c46ad2d7539b2731 137490 utils standard dpkg-dev_1.10.21_all.deb
 794381a64e07416e48af7d6bb4ae52d0 10620 doc optional dpkg-doc_1.10.21_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAi/2fIexP3IStZ2wRAn8pAJ9/rxk0uozGIQta1eA1i+IQZIQx9QCgpA1B
Hn7++hlhNM0b38XnzfCRzhg=
=GiSq
-----END PGP SIGNATURE-----

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

From: Scott James Remnant <scott@netsplit.com>

To: 146167-close@bugs.debian.org

Subject: Bug#146167: fixed in dpkg 1.10.21

Date: Sun, 25 Apr 2004 14:17:03 -0400

Source: dpkg
Source-Version: 1.10.21

We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive:

dpkg-dev_1.10.21_all.deb
  to pool/main/d/dpkg/dpkg-dev_1.10.21_all.deb
dpkg-doc_1.10.21_all.deb
  to pool/main/d/dpkg/dpkg-doc_1.10.21_all.deb
dpkg_1.10.21.dsc
  to pool/main/d/dpkg/dpkg_1.10.21.dsc
dpkg_1.10.21.tar.gz
  to pool/main/d/dpkg/dpkg_1.10.21.tar.gz
dpkg_1.10.21_i386.deb
  to pool/main/d/dpkg/dpkg_1.10.21_i386.deb
dselect_1.10.21_i386.deb
  to pool/main/d/dpkg/dselect_1.10.21_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 146167@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Scott James Remnant <scott@netsplit.com> (supplier of updated dpkg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 25 Apr 2004 18:55:10 +0100
Source: dpkg
Binary: dpkg-doc dpkg dselect dpkg-dev dpkg-static
Architecture: source all i386
Version: 1.10.21
Distribution: unstable
Urgency: low
Maintainer: Dpkg Development <debian-dpkg@lists.debian.org>
Changed-By: Scott James Remnant <scott@netsplit.com>
Description: 
 dpkg       - Package maintenance system for Debian
 dpkg-dev   - Package building tools for Debian
 dpkg-doc   - Dpkg Internals Documentation
 dselect    - a user tool to manage Debian packages
Closes: 10879 33046 47267 90623 98210 102094 109669 109691 115352 120970 124225 146167 151799 155456 158916 160761 161156 166052 171489 174973 174978 179192 187952 200701 200763 204275 207758 214699 219210 220776 225086 233614 237589 237624 237864 239000 240081 241503 242870 243191 244098 244316
Changes: 
 dpkg (1.10.21) unstable; urgency=low
 .
   * Fix incorrect linked list node removal code that caused every second
     shared or diverted conffile to be deleted by dpkg.
     Closes: #10879, #33046, #47267, #90623, #98210, #109691, #146167.
     Closes: #155456, #204275.
   * Call mknod with the required device type.  Closes: #158916.
   * Correct the default query output format to be consistent with
     what the underlying library expects.  Closes: #174973.
   * Fix missing NULL-termination in dpkg-query -W display of dependency
     fields.  Closes: #174978
   * Strip output from md5sum(1) after the first whitespace character.
     Closes: #200763.
   * Output a warning if we cannot open a configuration file instead of
     treating it as a fatal error, in case our home directory is not readable
     by root.  Closes: #200701.
   * Set LC_ALL to C before spawning off dpkg --search, to avoid searching
     on localized strings.  Closes: #244316.
   * Don't require argument for start-stop-daemon -V.  Closes: #237589.
   * Correct use of @ARGV within dpkg-scanpackages, allowing -u to work
     once again.  Closes: #225086, #241503.
   * Make sure file permissions passed to dpkg-statoverride are numeric.
     Closes: #161156.
   * Correctly break out of the loop in install-info.
     Closes: #124225, #160761.
   * Add --dir-file option to install-info for GNU install-info
     compatibility.  Closes: #179192
   * Refer to debian-policy in dpkg-doc's description instead of the
     non-existant packaging-manual.  Closes: #120970.
   * Remove incorrect mention of build-essential from dpkg-checkbuilddeps
     manpage.  Closes: #219210.
   * Add a note about diverting shared libraries to the dpkg-divert
     manpage.  Closes: #214699.
   * Updated Translations:
     - Brazilian Portugese (Andre Luis Lopes).  Closes: #237864.
     - Catalan (Jordi Mallach).
     - Danish (Claus Hindsgaul).  Closes: #237624.
     - Dutch (Pieter-Paul Spiertz, Bart Cornelis, Erwin).
       Closes: #102094, #151799, #207758.
     - French (Sam Hocevar).  Closes: #243191.
     - German (Florian Ernst).  Closes: #109669, #115352, #187952, #244098.
     - Japanese manpages (KISE Hiroshi).  Closes: #220776.
     - Polish (Bartosz Fenski).  Closes: #242870.
     - Spanish (Javier Fernández-Sanguino Peña).  Closes: #166052.
     - Swedish (Peter Karlsson).
   * New Translations:
     - Japanese dpkg-source manpage (KISE Hiroshi).  Closes: #239000.
     - Norwegian Nynorsk (Gaute Hvoslef Kvalnes).  Closes: #233614.
     - Portguese (Miguel Figueiredo).  Closes: #240081.
     - Spanish dpkg-source manpage (Ruben Porras).  Closes: #171489.
Files: 
 3c0ee1d26bd55362b92eee8e6255aee0 798 base required dpkg_1.10.21.dsc
 a9f6c43891db74d727beab7dfc0ee663 1682647 base required dpkg_1.10.21.tar.gz
 e492251ba4cf345982782b7880056e1f 1220962 base required dpkg_1.10.21_i386.deb
 132ac9df0f3dd8fd8b7adbf409f8ed3e 105530 base required dselect_1.10.21_i386.deb
 48e0a00caea19997c46ad2d7539b2731 137490 utils standard dpkg-dev_1.10.21_all.deb
 794381a64e07416e48af7d6bb4ae52d0 10620 doc optional dpkg-doc_1.10.21_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAi/2fIexP3IStZ2wRAn8pAJ9/rxk0uozGIQta1eA1i+IQZIQx9QCgpA1B
Hn7++hlhNM0b38XnzfCRzhg=
=GiSq
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.