Acknowledgement sent to Branden Robinson <branden@debian.org>:
New Bug report received and forwarded. Copy sent to Wichert Akkerman <wakkerma@debian.org>.
(full text, mbox, link).
Subject: Re: #108587: dpkg: falsely thinks that conffiles have been changed
by the user
Date: Sat, 15 Sep 2001 21:56:26 -0500 (CDT)
If you look at all the conffile prompting in the log, every single prompt
thinks you are overwriting an already existing file, that is not currently a
conffile.
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
This leads me to think that the Conffiles setting in status is getting
erased(likely) or corrupted(unlikely).
Tags added:
Request was from Wichert Akkerman <wichert@wiggy.net>
to control@bugs.debian.org.
(full text, mbox, link).
Tags added: unreproducible
Request was from Wichert Akkerman <wichert@wiggy.net>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to root <jlquinn@us.ibm.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org.
(full text, mbox, link).
To: Debian Bug Tracking System <108587@bugs.debian.org>
Subject: dpkg: Upgrade of hotplug thinks conffiles are modified
Date: Fri, 08 Feb 2002 13:54:17 -0500
Package: dpkg
Version: 1.9.18
dpkg incorrectly thinks that /etc/hotplug/hotplug.functions was modified and asks
me to resolve diffs during upgrade from hotplug 0.0.20010919-10 to
hotplug_0.0.20020114-4
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux wyvern 2.4.17-686 #2 Sat Dec 22 21:58:49 EST 2001 i686
Locale: LANG=C, LC_CTYPE=
Versions of packages dpkg depends on:
ii libc6 2.2.4-7 GNU C Library: Shared libraries an
ii libncurses5 5.2.20020112a-3 Shared libraries for terminal hand
ii libstdc++2.10-glibc2.2 1:2.95.4-1 The GNU stdc++ library
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Wichert Akkerman <wichert@wiggy.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org.
(full text, mbox, link).
To: root <jlquinn@us.ibm.com>, 108587@bugs.debian.org
Subject: Re: Bug#108587: dpkg: Upgrade of hotplug thinks conffiles are modified
Date: Sat, 9 Feb 2002 17:35:57 +0100
Previously root wrote:
> dpkg incorrectly thinks that /etc/hotplug/hotplug.functions was modified and asks
> me to resolve diffs during upgrade from hotplug 0.0.20010919-10 to
> hotplug_0.0.20020114-4
Can you reproduce that?
Wichert.
--
_________________________________________________________________
/wichert@wiggy.net This space intentionally left occupied \
| wichert@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to "Jerome L Quinn" <jlquinn@us.ibm.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org.
(full text, mbox, link).
How should I go about trying to reproduce it?
Jerry
Wichert Akkerman <wichert@wiggy.net> on 02/09/2002 11:35:57 AM
To: Jerome L Quinn/Watson/IBM@IBMUS, 108587@bugs.debian.org
cc:
Subject: Re: Bug#108587: dpkg: Upgrade of hotplug thinks conffiles are
modified
Previously root wrote:
> dpkg incorrectly thinks that /etc/hotplug/hotplug.functions was modified
and asks
> me to resolve diffs during upgrade from hotplug 0.0.20010919-10 to
> hotplug_0.0.20020114-4
Can you reproduce that?
Wichert.
--
_________________________________________________________________
/wichert@wiggy.net This space intentionally left occupied \
| wichert@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to "Jerome L Quinn" <jlquinn@us.ibm.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org.
(full text, mbox, link).
How would I go about reproducing it?
Jerry
Wichert Akkerman <wichert@wiggy.net> on 02/09/2002 11:35:57 AM
To: Jerome L Quinn/Watson/IBM@IBMUS, 108587@bugs.debian.org
cc:
Subject: Re: Bug#108587: dpkg: Upgrade of hotplug thinks conffiles are
modified
Previously root wrote:
> dpkg incorrectly thinks that /etc/hotplug/hotplug.functions was modified
and asks
> me to resolve diffs during upgrade from hotplug 0.0.20010919-10 to
> hotplug_0.0.20020114-4
Can you reproduce that?
Wichert.
--
_________________________________________________________________
/wichert@wiggy.net This space intentionally left occupied \
| wichert@deephackmode.org http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to jlquinn@us.ibm.com:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org.
(full text, mbox, link).
To: Debian Bug Tracking System <108587@bugs.debian.org>
Subject: dpkg: Same problem upgrading to tetex-bin_1.0.7+20011202-3.1
Date: Tue, 12 Feb 2002 19:57:44 -0500
Package: dpkg
Version: 1.9.18
dpkg thinks that /etc/texmf/texmf.cnf was modified and enters the
resolution dialog.
old version: tetex-bin 1.0.7+20011202-2
new version: tetex-bin_1.0.7+20011202-3.1_powerpc.deb
-- System Information
Debian Release: 3.0
Architecture: powerpc
Kernel: Linux dragon 2.4.17-rc1 #8 Sat Jan 12 22:16:34 EST 2002 ppc
Locale: LANG=C, LC_CTYPE=
Versions of packages dpkg depends on:
ii libc6 2.2.5-3 GNU C Library: Shared libraries an
ii libncurses5 5.2.20020112a-3 Shared libraries for terminal hand
ii libstdc++2.10-glibc2.2 1:2.95.4-1 The GNU stdc++ library
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Junichi Uekawa <dancer@netfort.gr.jp>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org.
(full text, mbox, link).
Subject: Re: Bug#108587: dpkg: Same problem upgrading to tetex-bin_1.0.7+20011202-3.1
Date: Thu, 14 Feb 2002 02:57:33 +0900
Jerry Quinn <jlquinn@optonline.net> cum veritate scripsit:
> Package: dpkg
> Version: 1.9.18
>
> dpkg thinks that /etc/texmf/texmf.cnf was modified and enters the
> resolution dialog.
It is modified in tetex postinst.
This is a bug in tetex.
>
> old version: tetex-bin 1.0.7+20011202-2
> new version: tetex-bin_1.0.7+20011202-3.1_powerpc.deb
--
dancer@debian.org : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Jerry Quinn <jlquinn@us.ibm.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org.
(full text, mbox, link).
To: Debian Bug Tracking System <108587@bugs.debian.org>
Subject: dpkg: same problem with viewcvs
Date: Wed, 13 Mar 2002 22:33:01 -0500
Package: dpkg
Version: 1.9.19
Upgrading from 0.9.2-2 to 0.9.2-3 claims that /etc/viewcvs/viewcvs.conf has
been changed and needs resolving with the new version. That file
hasn't been touched by me.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux wyvern 2.4.17-686 #2 Sat Dec 22 21:58:49 EST 2001 i686
Locale: LANG=C, LC_CTYPE=
Versions of packages dpkg depends on:
ii libc6 2.2.5-3 GNU C Library: Shared libraries an
ii libncurses5 5.2.20020112a-5 Shared libraries for terminal hand
ii libstdc++2.10-glibc2.2 1:2.95.4-1 The GNU stdc++ library
Changed Bug title.
Request was from Branden Robinson <branden@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to dpkg@packages.qa.debian.org: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and filed, but not forwarded. Copy sent to dpkg@packages.qa.debian.org.
(full text, mbox, link).
retitle 108587 dpkg: a conffile that vanishes across an upgrade can fool dpkg
retitle 182021 dpkg: reappearing conffile that had vanished fools dpkg
reassign 182021
merge 108587 182021
thanks
Adam Heath and I have discussed this on IRC.
Quoting the logs of #182021:
> /etc/X11/xkb/symbols/czsk is tagged as a configuration file, however it
> contains a version string. Consequently, the user is prompted during
> upgrade:
[...]
> Despite no changes having ever been made.
That's not why you're being prompted. You're being prompted because the
file stopped being shipped as part of the package a while back, but now
is being shipped again. Vanishing conffiles are not deleted when a
package is upgraded. Therefore, dpkg thinks you're installing a new
conffile on top of some non-packaged previously-existing version which
you must have created.
Dpkg is wrong, of course.
Dpkg has no mechanism to handle conffiles disappearing across upgrades.
> Is this just an implementation choice in dpkg, or is there
> insufficient information in the existing .deb files to enable
> dpkg to, say, remove unmodified configuration files when a
> package is being deleted, even if it's not being purged?
The latter.
> (It is conceivable that someone, somewhere is depending upon
> deletion-without-purging to leave even unmodified configuration
> files intact, but I assume that the idea behind
> deletion-without-purging is to preserve local _changes_, not
> just local copies of a removed package's standard out-of-the-box
> configuration.)
There should probably be a prompt for disappearing conffiles, similar to
the one that is used for changing conffiles.
--
G. Branden Robinson | Men use thought only to justify
Debian GNU/Linux | their wrong doings, and speech only
branden@debian.org | to conceal their thoughts.
http://people.debian.org/~branden/ | -- Voltaire
Merged 108587182021.
Request was from Branden Robinson <branden@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Subject: Re: May packages rm -rf subdirectories of /etc/ ?
Date: 21 Jul 2003 16:35:35 +0200
Herbert Xu <herbert@gondor.apana.org.au> wrote (to debian-devel):
> Unfortunately dpkg does not handle the case where a conffile
> ceases to exist in a later version of a package. The conffile
> will be left on the system even after purging.
Agreed, dpkg should do something reasonable when a package
is replaced and the new version doesn't list all the
conffiles that the old one did. I'd say that it should
rename such conffiles to $NAME.dpkg-old . Would that be enough,
or should the user be asked about it?
I am cc:ing this to #108587 (and to people who commented on it)
which already asks for dpkg to handle disappearing conffiles
properly.
--
Thomas
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Wichert Akkerman <wichert@wiggy.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Subject: Re: May packages rm -rf subdirectories of /etc/ ?
Date: Mon, 21 Jul 2003 16:39:08 +0200
Previously Thomas Hood wrote:
> Agreed, dpkg should do something reasonable when a package
> is replaced and the new version doesn't list all the
> conffiles that the old one did. I'd say that it should
> rename such conffiles to $NAME.dpkg-old . Would that be enough,
> or should the user be asked about it?
That would be horrible since that extension is already used for a
different purpose and might silently remove useful data.
The real question is: what is reasonable behaviour? Keeping the file as
it is sounds reasonable to me: other (possibly modified) files might
refer to it and might suddenly break if a file is removed. An example
of this is upstream renaming or obsoleting conffiles that other tools
also happen to use (this is happening right now in freeradius).
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Message sent on to Branden Robinson <branden@debian.org>:
Bug#108587.
(full text, mbox, link).
Message sent on to Branden Robinson <branden@debian.org>:
Bug#108587.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Subject: Re: May packages rm -rf subdirectories of /etc/ ?
Date: 21 Jul 2003 16:59:44 +0200
On Mon, 2003-07-21 at 16:39, Wichert Akkerman wrote:
> That would be horrible since that extension is already used for a
> different purpose and might silently remove useful data.
The scenario is: foo 1.0 (with conffile /etc/foo.conf) is replaced
by foo 2.0 (without that conffile).
The new package does not have a new copy of this file, so there is
no /etc/foo.conf.dpkg-old arising from the current upgrade. If a
/etc/foo.conf.dpkg-old is overwritten, it is one left over from an
earlier upgrade; but that is acceptable, no?
The reason I suggested foo.dpkg-old is that .dpkg-old is an extention
that programs already ignore. However, we could also use something
like ".dpkg-obsolete".
> The real question is: what is reasonable behaviour?
Yes.
> Keeping the file as
> it is sounds reasonable to me: other (possibly modified) files might
> refer to it and might suddenly break if a file is removed. An example
> of this is upstream renaming or obsoleting conffiles that other tools
> also happen to use (this is happening right now in freeradius).
What you describe doesn't happen if packages are following policy.
According to policy, a package can only rely on a configuration
file that it owns or that belongs to a package upon which it
Depends. In our scenario, the /etc/foo.conf has NO owner after
foo is upgraded.
Policy 10.7.4:
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 owner of the configuration file, i.e.,
it will be the package which handles that file as a configuration
file. Other packages that use the configuration file must depend
on the owning package if they require the configuration file to
operate.
--
Thomas Hood
Message sent on to Branden Robinson <branden@debian.org>:
Bug#108587.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Wichert Akkerman <wichert@wiggy.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Subject: Re: May packages rm -rf subdirectories of /etc/ ?
Date: Mon, 21 Jul 2003 17:09:12 +0200
Previously Thomas Hood wrote:
> The new package does not have a new copy of this file, so there is
> no /etc/foo.conf.dpkg-old arising from the current upgrade.
A more likely scenario:
* package A has conffile /etc/A
* user modified /etc/A
* package A makes a change in conffile, so now we have /etc/A and
/etc/A.dpkg-old
* package A no longer uses /etc/A or renames it
User upgrades A, dpkg overwrites /etc/A.dpkg-old without asking uses
since he didn't change the current version of the conffile and looses
his earlier customisation which was in /etc/A.dpkg-old.
> What you describe doesn't happen if packages are following policy.
> According to policy, a package can only rely on a configuration
> file that it owns or that belongs to a package upon which it
> Depends. In our scenario, the /etc/foo.conf has NO owner after
> foo is upgraded.
Debian policy isn't everything, dpkg is used in non-Debian environments
which do not use Debian policy. There are also many custom applications
that are not part of Debian that you have to take into account.
Finally, the bit of policy you quote does not cover this situation: if
a package B depends on A since it uses a conffile from A it will still
break when A no longer ships that conffile. So in fact if you want to
prevent breakage from policy-complient packages it is important *not*
to rename or remove conffiles.
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Message sent on to Branden Robinson <branden@debian.org>:
Bug#108587.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Herbert Xu <herbert@gondor.apana.org.au>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Subject: Re: May packages rm -rf subdirectories of /etc/ ?
Date: Tue, 22 Jul 2003 07:21:04 +1000
On Mon, Jul 21, 2003 at 04:39:08PM +0200, Wichert Akkerman wrote:
>
> The real question is: what is reasonable behaviour? Keeping the file as
What about this?
Treat the disappearence of a conffile the same way as you treat any
other changes. Prompt the user as usual, if they answer yes, then
rename the file to .dpkg-old. Otherwise do nothing.
Dpkg will still need to remember the .dpkg-old file so that later
on it can purge it.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Message sent on to Branden Robinson <branden@debian.org>:
Bug#108587.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
On Tue, Jul 22, 2003 at 07:21:04AM +1000, Herbert Xu wrote:
> On Mon, Jul 21, 2003 at 04:39:08PM +0200, Wichert Akkerman wrote:
> >
> > The real question is: what is reasonable behaviour? Keeping the file as
>
> What about this?
>
> Treat the disappearence of a conffile the same way as you treat any
> other changes. Prompt the user as usual, if they answer yes, then
> rename the file to .dpkg-old. Otherwise do nothing.
>
> Dpkg will still need to remember the .dpkg-old file so that later
> on it can purge it.
As much as I hate prompting, this is what I personally always had in
mind.
It's too hard to know what the right thing to do is. Best to prompt.
--
G. Branden Robinson | It's not a matter of alienating
Debian GNU/Linux | authors. They have every right to
branden@debian.org | license their software however we
http://people.debian.org/~branden/ | like. -- Craig Sanders
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Subject: Re: Bug#108587: May packages rm -rf subdirectories of /etc/ ?
Date: 22 Jul 2003 07:24:51 +0200
On Tue, 2003-07-22 at 06:30, Branden Robinson wrote:
> On Tue, Jul 22, 2003 at 07:21:04AM +1000, Herbert Xu wrote:
> > What about this?
> >
> > Treat the disappearence of a conffile the same way as you treat any
> > other changes. Prompt the user as usual, if they answer yes, then
> > rename the file to .dpkg-old. Otherwise do nothing.
> >
> > Dpkg will still need to remember the .dpkg-old file so that later
> > on it can purge it.
>
> As much as I hate prompting, this is what I personally always had in
> mind.
>
> It's too hard to know what the right thing to do is. Best to prompt.
Wichert Akkerman made the point that in some cases you
have a package B that Depends on package A and uses /etc/A.conf .
A new A is released that no longer contains /etc/A.conf . The
new situation is broken and policy-non-compliant no matter how
you look at it; but what is the safest thing to do? Wichert
argues that the safest thing to do is to leave the file alone.
Now, the above proposal is that an offer be made to the admin to
rename A.conf to A.conf.dpkg-old . In recognition of Wichert's
failure scenario, the prompt should at least warn the admin that
agreeing to rename the file _could_ break packages that Depend
on A.
--
Thomas
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
On Tue, Jul 22, 2003 at 07:24:51AM +0200, Thomas Hood wrote:
> Now, the above proposal is that an offer be made to the admin to
> rename A.conf to A.conf.dpkg-old . In recognition of Wichert's
> failure scenario, the prompt should at least warn the admin that
> agreeing to rename the file _could_ break packages that Depend
> on A.
No objection. If the admin is concerned he should be able to background
the prompt and investigate just as with the current
changed-conffile-overwrite prompt.
--
G. Branden Robinson | That's the saving grace of humor:
Debian GNU/Linux | if you fail, no one is laughing at
branden@debian.org | you.
http://people.debian.org/~branden/ | -- A. Whitney Brown
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Wichert Akkerman <wichert@wiggy.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Cc: 108587@bugs.debian.org, Thomas Hood <jdthood@yahoo.co.uk>,
Herbert Xu <herbert@gondor.apana.org.au>, doogie@debian.org,
jlquinn@us.ibm.com, Junichi Uekawa <dancer@netfort.gr.jp>
Subject: Re: Bug#108587: May packages rm -rf subdirectories of /etc/ ?
Date: Tue, 22 Jul 2003 22:53:31 +0200
Previously Branden Robinson wrote:
> No objection. If the admin is concerned he should be able to background
> the prompt and investigate just as with the current
> changed-conffile-overwrite prompt.
I'll see if I can work that into the new conffile handling code.
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Subject: Re: May packages rm -rf subdirectories of /etc/ ?
Date: 24 Jul 2003 13:12:58 +0200
On Thu, 2003-07-24 at 08:47, Andreas Metzler wrote:
> It really sucks to handle this if you want/need to get rid of it (if
> it is unmodified) not only on purge but on upgrades. - You'll need
>
> if [ "$1" = "configure" ] && \
> dpkg --compare-versions "$2" le-nl "1.2.3" && \
> [ -e /etc/foo ] && \
> [ `md5sum /etc/foo | cut -d\ -f1` = "6bea09fbb18e4676012105fa5fc726c6" ]
> then
> echo "Removing orphaned unmodified configfile /etc/foo" 1>&2
> rm /etc/foo
> fi
In a discussion that followed from this thread off-list, some
people agreed that the administrator should be asked what
he or she wants to do with an obsolete conffile. The conffile
should not be deleted silently because other packages may be
using the file.
Here is how I see it. On install of the new version of foo
which lacks the former foo conffile /etc/foo.conf,
* dpkg informs the user that /etc/foo.conf is no longer a
conffile of foo;
* dpkg says whether or not /etc/foo.conf was changed from the
original;
* dpkg offers to display the file, to start a shell so that
the user can check things out, or to do one of three things
to the file:
* leave the file as it is (= the current behavior),
* delete the file (= the default if the file has not been changed),
or,
* rename the file to /etc/foo.conf.dpkg-old (= the default if
the file has been changed)
--
Thomas
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Subject: Re: May packages rm -rf subdirectories of /etc/ ?
Date: 24 Jul 2003 14:07:35 +0200
On Thu, 2003-07-24 at 13:46, Stephen Frost wrote:
> I see this as totally bogus. Either the conffile is shared or it isn't.
> If it's shared then the packages involved know this
Package foo which eliminates /etc/foo.conf doesn't "know"
that there is not some other package, bar, which Depends
on foo and uses /etc/foo.conf . That's the problem. See
#108587 for additional discussion.
--
Thomas
Tags removed: unreproducible
Request was from Thomas Hood <jdthood@yahoo.co.uk>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Stephen Frost <sfrost@snowman.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
* Thomas Hood (jdthood@yahoo.co.uk) wrote:
> On Thu, 2003-07-24 at 13:46, Stephen Frost wrote:
> > I see this as totally bogus. Either the conffile is shared or it isn't.
> > If it's shared then the packages involved know this
>
> Package foo which eliminates /etc/foo.conf doesn't "know"
> that there is not some other package, bar, which Depends
> on foo and uses /etc/foo.conf . That's the problem. See
> #108587 for additional discussion.
The maintainer should really know. The maintainer is more likely to
know than the user in many cases. I think it would be worthwhile for
policy to be modified to require notification when a sharing of this
kind happens. I know that I'd expect someone to tell me if they're
using a conffile from my package.
Stephen
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
To: debian-devel@lists.debian.org, 108587@bugs.debian.org
Subject: Re: May packages rm -rf subdirectories of /etc/ ?
Date: 24 Jul 2003 15:06:59 +0200
On Thu, 2003-07-24 at 14:53, Stephen Frost wrote:
> * Thomas Hood (jdthood@yahoo.co.uk) wrote:
> > Package foo which eliminates /etc/foo.conf doesn't "know"
> > that there is not some other package, bar, which Depends
> > on foo and uses /etc/foo.conf . That's the problem. See
> > #108587 for additional discussion.
>
> The maintainer should really know. The maintainer is more likely to
> know than the user in many cases. I think it would be worthwhile for
> policy to be modified to require notification when a sharing of this
> kind happens. I know that I'd expect someone to tell me if they're
> using a conffile from my package.
If this were required in policy, then there ought to be an easy
way to comply. We could allow packages to list Conffiles that
are not shipped with the package; these would have to be included
in some package upon which the dependent package Depends. That
would give dpkg the information it needs to decide whether it
is OK to delete the conffile when foo abandons it. If bar listed
foo.conf as a conffile, then bar could inherit the file when foo
abandoned it.
Perhaps that could be made to work, but it would be complex,
and dpkg is already beyond the capacity of Debian to maintain
properly.
--
Thomas
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
Subject: Re: May packages rm -rf subdirectories of /etc/ ?
Date: 25 Jul 2003 09:20:20 +0200
On Fri, 2003-07-25 at 07:59, Manoj Srivastava wrote:
> Umm. apt allows you to determine reverse depends. From there
> there is an easy hop to sending email to ask the develoeprsa in
> question; or to exaimine a package to look at its conffiles.
This doesn't solve the problem of the dependent package being
broken by the removal of the conffile upon which it has been
depending. A _new_ version of the dependent package may have
been released to the archive, but this is not the version that
the victim has installed on his computer.
Nick Phillips made a good point, however, when he said that
conffiles are no different from other files in this respect.
If bar depends on foo, then bar might be broken if _any_ file
is removed from foo. Yet we do not do anything special when
foo version 2.0 lacks an ordinary file that was contained in foo
version 1.0. So we should not do anything special for conffiles
either but (as Manoj Srivastava says) we should rely on
communication among maintainers to avoid problems.
Conffiles are different in one respect, which that is that they
can be locally modified. When a conffile is to be overwritten
and it has been modified, the user is asked for permission and
the old version is backed up as *.dpkg-old. So when a conffile
is to be deleted and it has been modified, the user should be
asked for permission and the file renamed to *.dpkg-old
(or *.dpkg-orphaned). Agree?
--
Thomas
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Thomas Hood <jdthood@yahoo.co.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>.
(full text, mbox, link).
I think we have heard all sides of this now (in debian-devel)
I conclude that dpkg should deal with an obsolete conffile in
the following way.
If the conffile has not been locally modified, delete it.
If the conffile has been locally modified, ask the user for
permission to eliminate the file; if permission is granted
then rename the file to *.dpkg-obsolete .
Thanks
--
Thomas
Changed Bug title.
Request was from Adam Heath <doogie@brainfood.com>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Scott James Remnant <scott@netsplit.com>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Scott James Remnant <scott@netsplit.com>.
(full text, mbox, link).
This bug (the lack of proper handling of a disappeared conffile) also
causes a spurious conffile prompt in the following case:
A version 1: /etc/zork.conf, conffile
A version 2: no file
B version 1: no file
B version 2: /etc/zork.conf, conffile
Now if A is upgraded before B, then after A's upgrade the conffile is
left existing but dpkg has forgotten all about it. Then when B is
upgrade it looks like the user wrote the conffile and you get a prompt.
I agree with Thomas Hood's specification of the correct behaviour,
except that I would say that .dpkg-old is a perfectly good name for
the obsolete file.
Ian.
Information forwarded to debian-bugs-dist@lists.debian.org, Scott James Remnant <scott@netsplit.com>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Scott James Remnant <scott@netsplit.com>.
(full text, mbox, link).
Subject: dpkg vanishing conffiles - more complex/complete specification
Date: Fri, 26 Aug 2005 17:17:51 +0100
This turns out to be somewhat harder than it looks.
dpkg does conffile processing during configuration. If anything goes
wrong during conffile processing, it stops there; it does not
(currently) keep a record in the status file of which conffiles have
been processed and which are as yet undone. Instead, the processing
of each individual conffile is made idempotent. That way a second
dpkg run can tell if this file has already been processed.
The way this is done is that the new package's version of the file is
left in .dpkg-new from the unpack phase. The processing renames it
away to a different name. So an unprocessed conffile has a .dpkg-new
and a processed one does not. However in the case of a disappearing
conffile there is no .dpkg-new, so it is not easy to tell what's going
on.
Also, since the file has been removed from the new package, currently,
once the new package has been unpacked, there is no record of it in
dpkg's databases.
I propose the following new arrangements:
* Until the conffile is processed (during configuration), it remains
owned by the package and listed in its .list file and Conffiles
field even though the new version of the package doesn't contain
the file.
* However, we introduce a new syntax in the Conffiles status file
field: optionally, after the md5sum, we add the annotation
`disappearing'. This annotation is there exactly in the case where
the conffile is only listed as part of the package because it was
in a _previous_ version of the package and we haven't completed the
conffile processing yet.
* During the end of unpack processing, while the old files (ones on
the old but not the new package) are being removed from the file
list, if the old file was a conffile, we retain its entry in the
status file's Conffiles field, with the old original hash, and we
retain its entry in the file list. We add the `disappearing'
annotation to the Conffiles entry.
* During conffile processing, we check for the disappearing flag. If
so we don't treat the nonexistence of the .dpkg-new file as telling
us that the file has already been processed. Strictly, in this
order, for each conffile:
1. check for .dpkg-new and `disappearing':
.dpkg-new nonexistent not disappearing already done, do nothing
.dpkg-new nonexistent disappearing goto 2, new arrangements
.dpkg-new exists not disappearing process as we used to
.dpkg-new exists disappearing error
2. check if locally modified; if not (or if file does not
exist): delete it (if necessary) and goto 5.
3. ask user what to do
4. rename file to .dpkg-old if user says so, or just leave it
(these two steps are where we do the algorithm Thomas Hood
suggests, as modified by my followup).
5. post update to <package>.list and status file (in that order) with
all trace of this file removed.
* When we take over a Conffile entry from one package to another,
during unpack, we clear the disappearing flag.
Ian.
Information forwarded to debian-bugs-dist@lists.debian.org, Scott James Remnant <scott@netsplit.com>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Scott James Remnant <scott@netsplit.com>.
(full text, mbox, link).
Subject: Re: dpkg vanishing conffiles - more complex/complete specification
Date: Wed, 31 Aug 2005 18:26:40 +0100
Ian Jackson writes ("dpkg vanishing conffiles - more complex/complete specification"):
> * During conffile processing, [...]
How does dpkg know whether the conffile is has been removed from the
package and its conffiles because it's obsolete (in which case the
user should be asked whether to remove it) and it's been removed
because it's changing from a conffile to a maintainer-script handled
config file ?
I don't think dpkg has any way to tell at the moment. The package
maintainer would have to say. And, for existing packages, something
approaching the current behaviour is sensible to avoid breaking stuff.
So, I'll rename "disappearing" to "obsolete" and not do any
configure-stage processing at all. But we'll leave the file as part
of the package's files list and conffiles list, which will at least
make purge work properly and allow any new package which takes over
the file to get the full conffile record.
New scheme:
* During unpack, when an existing conffile is not present in the new
archive, it remains owned by the package and listed in its .list
file and Conffiles field even though the new version of the package
doesn't contain the file.
* However, we introduce a new syntax in the Conffiles status file
field: optionally, after the md5sum, we add the annotation
`obsolete'. This annotation is there exactly in the case where the
conffile is only listed as part of the package because it was in a
_previous_ version of the package.
* During the end of unpack processing, while the old files (ones on
the old but not the new package) are being removed from the file
list, if the old file was a conffile, we retain its entry in the
status file's Conffiles field, with the old original hash, and we
retain its entry in the file list. We add the `obsolete'
annotation to the Conffiles entry.
* During conffile processing, the disappeared conffile will never
have a .dpkg-new so we will simply skip it.
* When we take over a Conffile entry from one package to another,
during unpack, we clear the disappearing flag.
* Purge will automatically pick up the new entry and purge the old
file.
Ian.
Information forwarded to debian-bugs-dist@lists.debian.org, Scott James Remnant <scott@netsplit.com>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Scott James Remnant <scott@netsplit.com>.
(full text, mbox, link).
Ian Jackson writes ("Re: dpkg vanishing conffiles - more complex/complete specification"):
> New scheme:
> * During unpack, [...]
I have implemented this and tested it and it works for me. It fixes
the spurious conffile prompt I was seeing and appears to work
otherwise.
Attached is a patch against 1.13.11 (which also applies to
1.13.10ubuntu2 although I haven't checked whether that latter result
compiles or works).
Only in dpkg-1.13.11: build-tree
diff -ru orig/dpkg-1.13.11/debian/changelog dpkg-1.13.11/debian/changelog
--- orig/dpkg-1.13.11/debian/changelog 2005-08-17 04:45:20.000000000 +0100
+++ dpkg-1.13.11/debian/changelog 2005-09-01 16:20:50.000000000 +0100
@@ -1,3 +1,10 @@
+dpkg (1.13.11.0.99.iwj.0) unstable; urgency=low
+
+ * Improve processing of disappearing conffiles.
+ This is part of the fix for Debian bug #108587.
+
+ -- Ian Jackson <ian@davenant.greenend.org.uk> Thu, 1 Sep 2005 16:20:50 +0100
+
dpkg (1.13.11) unstable; urgency=low
The "Good, clean fun" Release.
Only in dpkg-1.13.11/debian: dpkg
Only in dpkg-1.13.11/debian: dpkg-dev
Only in dpkg-1.13.11/debian: dpkg.substvars
Only in dpkg-1.13.11/debian: dselect
Only in dpkg-1.13.11/debian: dselect.substvars
Only in dpkg-1.13.11/debian: files
Only in dpkg-1.13.11/debian: tmp
diff -ru orig/dpkg-1.13.11/lib/dpkg-db.h dpkg-1.13.11/lib/dpkg-db.h
--- orig/dpkg-1.13.11/lib/dpkg-db.h 2005-06-10 10:28:24.000000000 +0100
+++ dpkg-1.13.11/lib/dpkg-db.h 2005-09-01 12:25:16.000000000 +0100
@@ -84,6 +84,7 @@
struct conffile *next;
const char *name;
const char *hash;
+ int obsolete;
};
struct filedetails {
diff -ru orig/dpkg-1.13.11/lib/dump.c dpkg-1.13.11/lib/dump.c
--- orig/dpkg-1.13.11/lib/dump.c 2005-06-06 05:07:12.000000000 +0100
+++ dpkg-1.13.11/lib/dump.c 2005-09-01 12:25:16.000000000 +0100
@@ -233,6 +233,7 @@
if (i!=pifp->conffiles) varbufaddc(vb,'\n');
varbufaddc(vb,' '); varbufaddstr(vb,i->name); varbufaddc(vb,' ');
varbufaddstr(vb,i->hash);
+ if (i->obsolete) varbufaddstr(vb," obsolete");
}
if (flags&fw_printheader)
varbufaddc(vb,'\n');
diff -ru orig/dpkg-1.13.11/lib/fields.c dpkg-1.13.11/lib/fields.c
--- orig/dpkg-1.13.11/lib/fields.c 2005-06-06 05:07:12.000000000 +0100
+++ dpkg-1.13.11/lib/fields.c 2005-09-01 16:13:51.000000000 +0100
@@ -222,13 +222,38 @@
"in Config-Version string `%.250s': %.250s"),value,emsg);
}
+void conffvalue_lastword(const char *value, const char *from,
+ const char *endent,
+ const char **word_start_r, int *word_len_r,
+ const char **new_from_r,
+ const char *filename, int lno,
+ FILE *warnto, int *warncount, struct pkginfo *pigp) {
+ /* the code in f_conffiles ensures that value[-1]==' ', which is helpful */
+ const char *lastspc;
+
+ if (from <= value+1) goto malformed;
+ for (lastspc= from-1; *lastspc != ' '; lastspc--);
+ if (lastspc <= value+1 || lastspc >= endent-1) goto malformed;
+
+ *new_from_r= lastspc;
+ *word_start_r= lastspc + 1;
+ *word_len_r= (int)(from - *word_start_r);
+ return;
+
+malformed:
+ parseerr(NULL,filename,lno, warnto,warncount,pigp,0,
+ _("value for `conffiles' has malformatted line `%.*s'"),
+ (int)(endent-value > 250 ? 250 : endent-value), value);
+}
+
void f_conffiles(struct pkginfo *pigp, struct pkginfoperfile *pifp,
enum parsedbflags flags,
const char *filename, int lno, FILE *warnto, int *warncount,
const char *value, const struct fieldinfo *fip) {
+ static const char obsolete_str[]= "obsolete";
struct conffile **lastp, *newlink;
- const char *endent, *endfn;
- int c, namelen, hashlen;
+ const char *endent, *endfn, *hashstart;
+ int c, namelen, hashlen, obsolete;
char *newptr;
lastp= &pifp->conffiles;
@@ -238,11 +263,15 @@
if (c != ' ') parseerr(NULL,filename,lno, warnto,warncount,pigp,0, _("value for"
" `conffiles' has line starting with non-space `%c'"), c);
for (endent= value; (c= *endent)!=0 && c != '\n'; endent++);
- for (endfn= endent; *endfn != ' '; endfn--);
- if (endfn <= value+1 || endfn >= endent-1)
- parseerr(NULL,filename,lno, warnto,warncount,pigp,0,
- _("value for `conffiles' has malformatted line `%.*s'"),
- (int)(endent-value > 250 ? 250 : endent-value), value);
+ conffvalue_lastword(value, endent, endent,
+ &hashstart, &hashlen, &endfn,
+ filename,lno,warnto,warncount,pigp);
+ obsolete= (hashlen == sizeof(obsolete_str)-1 &&
+ !memcmp(hashstart, obsolete_str, hashlen));
+ if (obsolete)
+ conffvalue_lastword(value, endfn, endent,
+ &hashstart, &hashlen, &endfn,
+ filename,lno,warnto,warncount,pigp);
newlink= nfmalloc(sizeof(struct conffile));
value= skip_slash_dotslash(value);
namelen= (int)(endfn-value);
@@ -253,9 +282,10 @@
memcpy(newptr+1,value,namelen);
newptr[namelen+1]= 0;
newlink->name= newptr;
- hashlen= (int)(endent-endfn)-1; newptr= nfmalloc(hashlen+1);
- memcpy(newptr,endfn+1,hashlen); newptr[hashlen]= 0;
+ newptr= nfmalloc(hashlen+1);
+ memcpy(newptr,hashstart,hashlen); newptr[hashlen]= 0;
newlink->hash= newptr;
+ newlink->obsolete= obsolete;
newlink->next =NULL;
*lastp= newlink;
lastp= &newlink->next;
diff -ru orig/dpkg-1.13.11/src/archives.c dpkg-1.13.11/src/archives.c
--- orig/dpkg-1.13.11/src/archives.c 2005-08-14 19:23:51.000000000 +0100
+++ dpkg-1.13.11/src/archives.c 2005-09-01 15:55:55.000000000 +0100
@@ -315,14 +315,25 @@
errno= e; return r;
}
+struct fileinlist *addfiletolist(struct tarcontext *tc,
+ struct filenamenode *namenode) {
+ struct fileinlist *nifd;
+
+ nifd= obstack_alloc(&tar_obs, sizeof(struct fileinlist));
+ nifd->namenode= namenode;
+ nifd->next= 0; *tc->newfilesp= nifd; tc->newfilesp= &nifd->next;
+ return nifd;
+}
+
int tarobject(struct TarInfo *ti) {
static struct varbuf conffderefn, hardlinkfn, symlinkfn;
const char *usename;
-
+
+ struct conffile *conff;
struct tarcontext *tc= (struct tarcontext*)ti->UserData;
int statr, fd, i, existingdirectory, keepexisting;
size_t r;
- struct stat stab, stabd;
+ struct stat stab, stabtmp;
char databuf[TARBLKSZ];
struct fileinlist *nifd, **oldnifd;
struct pkginfo *divpkg, *otherpkg;
@@ -336,9 +347,7 @@
* been stripped by TarExtractor (lib/tarfn.c).
*/
oldnifd= tc->newfilesp;
- nifd= obstack_alloc(&tar_obs, sizeof(struct fileinlist));
- nifd->namenode= findnamenode(ti->Name, 0);
- nifd->next= 0; *tc->newfilesp= nifd; tc->newfilesp= &nifd->next;
+ nifd= addfiletolist(tc, findnamenode(ti->Name, 0));
nifd->namenode->flags |= fnnf_new_inarchive;
debug(dbg_eachfile,
@@ -417,7 +426,7 @@
break;
case Directory:
/* If it's already an existing directory, do nothing. */
- if (!stat(fnamevb.buf,&stabd) && S_ISDIR(stabd.st_mode)) {
+ if (!stat(fnamevb.buf,&stabtmp) && S_ISDIR(stabtmp.st_mode)) {
debug(dbg_eachfiledetail,"tarobject Directory exists");
existingdirectory= 1;
}
@@ -463,6 +472,29 @@
if (otherpkg->status == stat_configfiles) continue;
/* Perhaps we're removing a conflicting package ? */
if (otherpkg->clientdata->istobe == itb_remove) continue;
+
+ /* Is the file an obsolete conffile in the other package
+ * and a conffile in the new package ? */
+ if ((nifd->namenode->flags & fnnf_new_conff) &&
+ !statr && S_ISREG(stab.st_mode)) {
+ for (conff= otherpkg->installed.conffiles;
+ conff;
+ conff= conff->next) {
+ if (!conff->obsolete)
+ continue;
+ if (stat(conff->name, &stabtmp))
+ if (errno == ENOENT || errno == ENOTDIR || errno == ELOOP)
+ continue;
+ if (stabtmp.st_dev == stab.st_dev &&
+ stabtmp.st_ino == stab.st_ino)
+ break;
+ }
+ if (conff)
+ debug(dbg_eachfiledetail,"tarobject other's obsolete conffile");
+ /* processarc.c will have copied its hash already. */
+ continue;
+ }
+
if (does_replace(tc->pkg,&tc->pkg->available,otherpkg)) {
printf(_("Replacing files in old package %s ...\n"),otherpkg->name);
otherpkg->clientdata->replacingfilesandsaid= 1;
@@ -1103,5 +1135,17 @@
}
}
+struct fileinlist *newconff_append(struct fileinlist ***newconffileslastp_io,
+ struct filenamenode *namenode) {
+ struct fileinlist *newconff;
+
+ newconff= m_malloc(sizeof(struct fileinlist));
+ newconff->next= 0;
+ newconff->namenode= namenode;
+ **newconffileslastp_io= newconff;
+ *newconffileslastp_io= &newconff->next;
+ return newconff;
+}
+
/* vi: ts=8 sw=2
*/
diff -ru orig/dpkg-1.13.11/src/archives.h dpkg-1.13.11/src/archives.h
--- orig/dpkg-1.13.11/src/archives.h 2005-06-06 05:07:12.000000000 +0100
+++ dpkg-1.13.11/src/archives.h 2005-09-01 12:59:17.000000000 +0100
@@ -66,6 +66,9 @@
void check_conflict(struct dependency *dep, struct pkginfo *pkg,
const char *pfilename);
+struct fileinlist *addfiletolist(struct tarcontext *tc,
+ struct filenamenode *namenode);
+
extern int cleanup_pkg_failed, cleanup_conflictor_failed;
#endif /* ARCHIVES_H */
diff -ru orig/dpkg-1.13.11/src/filesdb.h dpkg-1.13.11/src/filesdb.h
--- orig/dpkg-1.13.11/src/filesdb.h 2005-08-14 19:23:51.000000000 +0100
+++ dpkg-1.13.11/src/filesdb.h 2005-09-01 12:50:29.000000000 +0100
@@ -65,6 +65,7 @@
fnnf_new_conff= 000001, /* in the newconffiles list */
fnnf_new_inarchive= 000002, /* in the new filesystem archive */
fnnf_old_conff= 000004, /* in the old package's conffiles list */
+ fnnf_obs_conff= 000100, /* obsolete conffile */
fnnf_elide_other_lists= 000010, /* must remove from other packages' lists */
fnnf_no_atomic_overwrite= 000020, /* >=1 instance is a dir, cannot rename over */
fnnf_placed_on_disk= 000040, /* new file has been placed on the disk */
diff -ru orig/dpkg-1.13.11/src/help.c dpkg-1.13.11/src/help.c
--- orig/dpkg-1.13.11/src/help.c 2005-06-10 10:37:38.000000000 +0100
+++ dpkg-1.13.11/src/help.c 2005-09-01 15:05:57.000000000 +0100
@@ -430,23 +430,35 @@
while (searchconff) {
namenode= findnamenode(searchconff->name, 0); /* XXX */
namenode->flags |= fnnf_old_conff;
+ if (!namenode->oldhash)
+ namenode->oldhash= searchconff->hash;
debug(dbg_conffdetail, "oldconffsetflags `%s' namenode %p flags %o",
searchconff->name, namenode, namenode->flags);
searchconff= searchconff->next;
}
}
-int chmodsafe_unlink(const char *pathname) {
+int chmodsafe_unlink(const char *pathname, const char **failed) {
+ /* Sets *failed to `chmod' or `unlink' if those calls fail (which is
+ * always unexpected). If stat fails it leaves *failed alone. */
struct stat stab;
if (lstat(pathname,&stab)) return -1;
- if (S_ISREG(stab.st_mode) ? (stab.st_mode & 07000) :
- !(S_ISLNK(stab.st_mode) || S_ISDIR(stab.st_mode) ||
- S_ISFIFO(stab.st_mode) || S_ISSOCK(stab.st_mode))) {
+ *failed= N_("unlink");
+ return chmodsafe_unlink_statted(pathname, &stab, failed);
+}
+
+int chmodsafe_unlink_statted(const char *pathname, const struct stat *stab,
+ const char **failed) {
+ /* Sets *failed to `chmod'' if that call fails (which is always
+ * unexpected). If unlink fails it leaves *failed alone. */
+ if (S_ISREG(stab->st_mode) ? (stab->st_mode & 07000) :
+ !(S_ISLNK(stab->st_mode) || S_ISDIR(stab->st_mode) ||
+ S_ISFIFO(stab->st_mode) || S_ISSOCK(stab->st_mode))) {
/* We chmod it if it is 1. a sticky or set-id file, or 2. an unrecognised
- * object (ie, not a file, link, directory, fifo or socket
+ * object (ie, not a file, link, directory, fifo or socket)
*/
- if (chmod(pathname,0600)) return -1;
+ if (chmod(pathname,0600)) { *failed= N_("chmod"); return -1; }
}
if (unlink(pathname)) return -1;
return 0;
@@ -454,7 +466,7 @@
void ensure_pathname_nonexisting(const char *pathname) {
int c1;
- const char *u;
+ const char *u, *failed;
u= skip_slash_dotslash(pathname);
assert(*u);
@@ -462,15 +474,19 @@
debug(dbg_eachfile,"ensure_pathname_nonexisting `%s'",pathname);
if (!rmdir(pathname)) return; /* Deleted it OK, it was a directory. */
if (errno == ENOENT || errno == ELOOP) return;
+ failed= N_("delete");
if (errno == ENOTDIR) {
/* Either it's a file, or one of the path components is. If one
* of the path components is this will fail again ...
*/
- if (!chmodsafe_unlink(pathname)) return; /* OK, it was */
+ if (!chmodsafe_unlink(pathname, &failed)) return; /* OK, it was */
if (errno == ENOTDIR) return;
}
- if (errno != ENOTEMPTY) /* Huh ? */
- ohshite(_("failed to rmdir/unlink `%.255s'"),pathname);
+ if (errno != ENOTEMPTY) { /* Huh ? */
+ char mbuf[250];
+ snprintf(mbuf, sizeof(mbuf), N_("failed to %s `%%.255s'"), failed);
+ ohshite(_(mbuf),pathname);
+ }
c1= m_fork();
if (!c1) {
execlp(RM,"rm","-rf","--",pathname,(char*)0);
diff -ru orig/dpkg-1.13.11/src/main.h dpkg-1.13.11/src/main.h
--- orig/dpkg-1.13.11/src/main.h 2005-06-06 05:07:12.000000000 +0100
+++ dpkg-1.13.11/src/main.h 2005-09-01 13:01:13.000000000 +0100
@@ -61,9 +61,10 @@
cfof_prompt = 001,
cfof_keep = 002,
cfof_install = 004,
- cfof_backup = 0100,
- cfof_newconff = 0200,
- cfof_isnew = 0400,
+ cfof_backup = 00100,
+ cfof_newconff = 00200,
+ cfof_isnew = 00400,
+ cfof_isold = 01000,
cfom_main = 007,
cfo_keep = cfof_keep,
cfo_prompt_keep = cfof_keep | cfof_prompt,
@@ -103,6 +104,8 @@
void archivefiles(const char *const *argv);
void process_archive(const char *filename);
int wanttoinstall(struct pkginfo *pkg, const struct versionrevision *ver, int saywhy);
+struct fileinlist *newconff_append(struct fileinlist ***newconffileslastp_io,
+ struct filenamenode *namenode);
/* from update.c */
@@ -179,7 +182,9 @@
const char *pkgadminfile(struct pkginfo *pkg, const char *whichfile);
void oldconffsetflags(const struct conffile *searchconff);
void ensure_pathname_nonexisting(const char *pathname);
-int chmodsafe_unlink(const char *pathname); /* chmod 600, then unlink */
+int chmodsafe_unlink(const char *pathname, const char **failed);
+int chmodsafe_unlink_statted(const char *pathname, const struct stat *stab,
+ const char **failed);
void checkpath(void);
struct filenamenode *namenodetouse(struct filenamenode*, struct pkginfo*);
diff -ru orig/dpkg-1.13.11/src/processarc.c dpkg-1.13.11/src/processarc.c
--- orig/dpkg-1.13.11/src/processarc.c 2005-08-17 03:50:52.000000000 +0100
+++ dpkg-1.13.11/src/processarc.c 2005-09-01 15:05:43.000000000 +0100
@@ -68,7 +68,7 @@
struct pkginfo *pkg, *otherpkg, *divpkg;
char *cidir, *cidirrest, *p;
char *pfilenamebuf, conffilenamebuf[MAXCONFFILENAME];
- const char *pfilename, *newinfofilename;
+ const char *pfilename, *newinfofilename, *failed;
struct fileinlist *newconff, **newconffileslastp;
struct fileinlist *cfile;
struct reversefilelistiter rlistit;
@@ -81,7 +81,7 @@
DIR *dsd;
struct filenamenode *namenode;
struct dirent *de;
- struct stat stab;
+ struct stat stab, oldfs;
struct packageinlist *deconpil, *deconpiltemp;
cleanup_pkg_failed= cleanup_conflictor_failed= 0;
@@ -313,12 +313,10 @@
while (p > conffilenamebuf && isspace(p[-1])) --p;
if (p == conffilenamebuf) continue;
*p= 0;
- newconff= m_malloc(sizeof(struct fileinlist));
- newconff->next= 0;
- newconff->namenode= findnamenode(conffilenamebuf, 0);
- *newconffileslastp= newconff;
- newconffileslastp= &newconff->next;
- newconff->namenode->oldhash= NEWCONFFILEFLAG;
+ namenode= findnamenode(conffilenamebuf, 0);
+ namenode->oldhash= NEWCONFFILEFLAG;
+ newconff= newconff_append(&newconffileslastp, namenode);
+
/* Let's see if any packages have this file. If they do we
* check to see if they listed it as a conffile, and if they did
* we copy the hash across. Since (for plain file conffiles,
@@ -356,6 +354,7 @@
xit_conff_hashcopy_srch:
if (searchconff) {
newconff->namenode->oldhash= searchconff->hash;
+ /* we don't copy `obsolete'; it's not obsolete in the new package */
} else {
debug(dbg_conff,"process_archive conffile `%s' no package, no hash",
newconff->namenode->name);
@@ -523,8 +522,10 @@
* package isn't one we're already processing, and the package's
* list becomes empty as a result, we `vanish' the package. This
* means that we run its postrm with the `disappear' argument, and
- * put the package in the `not-installed' state. Its conffiles are
- * ignored and forgotten about.
+ * put the package in the `not-installed' state. If it had any
+ * conffiles, their hashes and ownership will have been transferred
+ * already, so we just ignore those and forget about them from the
+ * point of view of the disappearing package.
*
* NOTE THAT THE OLD POSTRM IS RUN AFTER THE NEW PREINST, since the
* files get replaced `as we go'.
@@ -592,8 +593,7 @@
*/
reversefilelist_init(&rlistit,pkg->clientdata->files);
while ((namenode= reversefilelist_next(&rlistit))) {
- if ((namenode->flags & fnnf_old_conff) ||
- (namenode->flags & fnnf_new_conff) ||
+ if ((namenode->flags & fnnf_new_conff) ||
(namenode->flags & fnnf_new_inarchive))
continue;
if (!stat(namenode->name,&stab) && S_ISDIR(stab.st_mode)) {
@@ -604,10 +604,30 @@
fnamevb.used= fnameidlu;
varbufaddstr(&fnamevb, namenodetouse(namenode,pkg)->name);
varbufaddc(&fnamevb,0);
- if (!rmdir(fnamevb.buf)) continue;
- if (errno == ENOENT || errno == ELOOP) continue;
- if (errno == ENOTDIR) {
+
+ if (lstat(fnamevb.buf, &oldfs)) {
+ if (!(errno == ENOENT || errno == ELOOP || errno == ENOTDIR))
+ fprintf(stderr,
+ _("dpkg: warning - could not stat old file `%.250s'"
+ " so not deleting it: %s"),
+ fnamevb.buf, strerror(errno));
+ continue;
+ }
+ if (S_ISDIR(oldfs.st_mode)) {
+ if (rmdir(fnamevb.buf)) {
+ fprintf(stderr,
+ _("dpkg: warning - unable to delete old directory"
+ " `%.250s': %s\n"), namenode->name, strerror(errno));
+ } else if ((namenode->flags & fnnf_old_conff)) {
+ fprintf(stderr,
+ _("dpkg: warning - old conffile `%.250s' was an empty"
+ " directory (and has now been deleted)\n"),
+ namenode->name);
+ }
+ } else {
/* Ok, it's an old file, but is it really not in the new package?
+ * It might be known by a different name because of symlinks.
+ *
* We need to check to make sure, so we stat the file, then compare
* it to the new list. If we find a dev/inode match, we assume they
* are the same file, and leave it alone. NOTE: we don't check in
@@ -618,54 +638,76 @@
* the process a little leaner. We are only worried about new ones
* since ones that stayed the same don't really apply here.
*/
- struct stat oldfs;
- int donotrm = 0;
+ struct fileinlist *sameas= 0;
/* If we can't stat the old or new file, or it's a directory,
* we leave it up to the normal code
*/
debug(dbg_eachfile, "process_archive: checking %s for same files on "
- "upgrade/downgrade", fnamevb.buf);
- if (!lstat(fnamevb.buf, &oldfs) && !S_ISDIR(oldfs.st_mode)) {
- for (cfile = newfileslist; cfile; cfile = cfile->next) {
- if (!cfile->namenode->filestat) {
- cfile->namenode->filestat = (struct stat *) nfmalloc(sizeof(struct stat));
- if (lstat(cfile->namenode->name, cfile->namenode->filestat)) {
- cfile->namenode->filestat= 0;
- continue;
- }
- }
- if (S_ISDIR(cfile->namenode->filestat->st_mode))
+ "upgrade/downgrade", fnamevb.buf);
+
+ for (cfile= newfileslist; cfile; cfile= cfile->next) {
+ if (!cfile->namenode->filestat) {
+ cfile->namenode->filestat= nfmalloc(sizeof(struct stat));
+ if (lstat(cfile->namenode->name, cfile->namenode->filestat)) {
+ if (!(errno == ENOENT || errno == ELOOP || errno == ENOTDIR))
+ ohshite(_("unable to stat other new file `%.250s'"),
+ cfile->namenode->name);
+ memset(cfile->namenode->filestat, 0,
+ sizeof(cfile->namenode->filestat));
continue;
- if (oldfs.st_dev == cfile->namenode->filestat->st_dev &&
- oldfs.st_ino == cfile->namenode->filestat->st_ino) {
- donotrm = 1;
- debug(dbg_eachfile, "process_archive: not removing %s, since it matches %s",
- fnamevb.buf, cfile->namenode->name);
}
}
- } else
- debug(dbg_eachfile, "process_archive: could not stat %s, skipping", fnamevb.buf);
- if (donotrm) continue;
- {
- /*
- * If file to remove is a device or s[gu]id, change its mode
- * so that a malicious user cannot use it even if it's linked
- * to another file.
- */
- struct stat stat_buf;
- if (lstat(fnamevb.buf,&stat_buf)==0) {
- if (S_ISCHR(stat_buf.st_mode) || S_ISBLK(stat_buf.st_mode))
- chmod(fnamevb.buf, 0);
- if (stat_buf.st_mode & (S_ISUID|S_ISGID))
- chmod(fnamevb.buf, stat_buf.st_mode & ~(S_ISUID|S_ISGID));
+ if (!cfile->namenode->filestat->st_mode) continue;
+ if (oldfs.st_dev == cfile->namenode->filestat->st_dev &&
+ oldfs.st_ino == cfile->namenode->filestat->st_ino) {
+ if (sameas)
+ fprintf(stderr, _("dpkg: warning - old file `%.250s' is the same"
+ " as several new files! (both `%.250s' and `%.250s'"),
+ fnamevb.buf,
+ sameas->namenode->name, cfile->namenode->name);
+ sameas= cfile;
+ debug(dbg_eachfile, "process_archive: not removing %s,"
+ " since it matches %s", fnamevb.buf, cfile->namenode->name);
}
}
- if (!unlink(fnamevb.buf)) continue;
- if (errno == ENOTDIR) continue;
- }
- fprintf(stderr,
- _("dpkg: warning - unable to delete old file `%.250s': %s\n"),
- namenode->name, strerror(errno));
+
+ if ((namenode->flags & fnnf_old_conff)) {
+ if (sameas) {
+ if (sameas->namenode->flags & fnnf_new_conff) {
+ if (!strcmp(sameas->namenode->oldhash, NEWCONFFILEFLAG)) {
+ sameas->namenode->oldhash= namenode->oldhash;
+ debug(dbg_eachfile, "process_archive: old conff %s"
+ " is same as new conff %s, copying hash",
+ namenode->name, sameas->namenode->name);
+ } else {
+ debug(dbg_eachfile, "process_archive: old conff %s"
+ " is same as new conff %s but latter already has hash",
+ namenode->name, sameas->namenode->name);
+ }
+ }
+ } else {
+ debug(dbg_eachfile, "process_archive: old conff %s"
+ " is disappearing", namenode->name);
+ namenode->flags |= fnnf_obs_conff;
+ newconff_append(&newconffileslastp, namenode);
+ addfiletolist(&tc, namenode);
+ }
+ continue;
+ }
+
+ if (sameas)
+ continue;
+
+ failed= N_("delete");
+ if (chmodsafe_unlink_statted(fnamevb.buf, &oldfs, &failed)) {
+ char mbuf[250];
+ snprintf(mbuf, sizeof(mbuf),
+ N_("dpkg: warning - unable to %s old file `%%.250s': %%s\n"),
+ failed);
+ fprintf(stderr, _(mbuf), namenode->name, strerror(errno));
+ }
+
+ } /* !S_ISDIR */
}
/* OK, now we can write the updated files-in-this package list,
@@ -827,6 +869,7 @@
newiconff->next= 0;
newiconff->name= nfstrsave(cfile->namenode->name);
newiconff->hash= nfstrsave(cfile->namenode->oldhash);
+ newiconff->obsolete= !!(cfile->namenode->flags & fnnf_obs_conff);
*iconffileslastp= newiconff;
iconffileslastp= &newiconff->next;
}
@@ -1033,6 +1076,8 @@
*
* Note that we don't ever delete things that were in the old
* package as a conffile and don't appear at all in the new.
+ * They stay recorded as obsolete conffiles and will eventually
+ * (if not taken over by another package) be forgotten.
*/
for (cfile= newfileslist; cfile; cfile= cfile->next) {
if (cfile->namenode->flags & fnnf_new_conff) continue;
diff -ru orig/dpkg-1.13.11/src/remove.c dpkg-1.13.11/src/remove.c
--- orig/dpkg-1.13.11/src/remove.c 2005-08-14 19:23:51.000000000 +0100
+++ dpkg-1.13.11/src/remove.c 2005-09-01 12:50:29.000000000 +0100
@@ -429,6 +429,11 @@
for (conff= pkg->installed.conffiles; conff; conff= conff->next) {
static struct varbuf fnvb, removevb;
+ if (conff->obsolete) {
+ debug(dbg_conffdetail, "removal_bulk conffile obsolete %s",
+ conff->name);
+ continue;
+ }
varbufreset(&fnvb);
r= conffderef(pkg, &fnvb, conff->name);
debug(dbg_conffdetail, "removal_bulk conffile `%s' (= `%s')",
Blocking bugs added: 108587, 182021, and 264790
Request was from Lars Wirzenius <liw@iki.fi>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Frank Lichtenheld <djpig@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>.
(full text, mbox, link).
To: Ian Jackson <ian@davenant.greenend.org.uk>, 108587@bugs.debian.org
Subject: Re: Bug#108587: dpkg vanishing conffiles - more complex/complete specification
Date: Mon, 30 Jan 2006 03:21:38 +0100
On Thu, Sep 01, 2005 at 04:33:09PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: dpkg vanishing conffiles - more complex/complete specification"):
> > New scheme:
> > * During unpack, [...]
>
> I have implemented this and tested it and it works for me. It fixes
> the spurious conffile prompt I was seeing and appears to work
> otherwise.
>
> Attached is a patch against 1.13.11 (which also applies to
> 1.13.10ubuntu2 although I haven't checked whether that latter result
> compiles or works).
Hi Ian.
Do you had any more conversation with Scott about this bug and the patch
or does this mail mark the latest status of it?
Just checking before investigating it for inclusion.
Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>.
(full text, mbox, link).
Cc: Scott James Remnant <scott@ubuntu.com>,
108587@bugs.debian.org
Subject: Re: Bug#108587: dpkg vanishing conffiles - more complex/complete specification
Date: Mon, 30 Jan 2006 10:57:58 +0000
Frank Lichtenheld writes ("Re: Bug#108587: dpkg vanishing conffiles - more complex/complete specification"):
> Do you had any more conversation with Scott about this bug and the patch
> or does this mail mark the latest status of it?
> Just checking before investigating it for inclusion.
Right. We have included the patch in Ubuntu and it is an
improvement. There is one new bug introduced; we don't have a writeup
of it but Scott just described it to me approximately like this: when
A Replaces B and both have a copy of the conffile it is sometimes
possible for B's conffile to be on disk when both A and B are
installed (presumably, when B was installed last).
We would like to fix this bug of course but we haven't got around to
it yet. So I would suggest that you include the patch in Debian and
we'll improve matters further when someone has the time and
inclination ...
Thanks,
Ian.
Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>: Bug#108587; Package dpkg.
(full text, mbox, link).
Acknowledgement sent to Frank Küster <frank@kuesterei.ch>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>.
(full text, mbox, link).
Subject: A conffile that vanished in an earlier version will be left after purge
Date: Tue, 12 Dec 2006 21:21:32 +0100
Dear dpkg team,
This is a new aspect of the well-known "a conffile that vanishes across
an upgrade can fool dpkg" bug. The conffile will not only be present
after the upgrade. Moreover, it will be left over if the package is
purged. I guess this might already be adressed by the Ubuntu patch, but
I wanted to be sure that this part of the problem is known. Here's an
example that shows the behavior.
Regards, Frank
Florent Rougon <f.rougon@free.fr> wrote:
> [ Starting point: lmodern 1.00-3 from sid is installed. ]
>
> # ll /etc/texmf/updmap.d
> total 16
> -rw-r--r-- 1 root root 2787 2006-10-14 19:30 00updmap.cfg
> -rw-r--r-- 1 root root 1681 2006-10-07 23:16 10lmodern.cfg
> -rw-r--r-- 1 root root 2623 2006-07-20 12:59 10tetex-base.cfg
> -rw-r--r-- 1 root root 1314 2006-07-20 12:59 20tetex-extra.cfg
>
> [ The following .deb contains lmodern 1.00-3 rebuilt with tex-common
> 0.42; therefore, it is *not* the same as the official 1.00-3. ]
>
> # dpkg -i ~flo/debian/lmodern/test2/lmodern_1.00-3_all.deb
> (Reading database ... 135646 files and directories currently installed.)
> Preparing to replace lmodern 1.00-3 (using .../test2/lmodern_1.00-3_all.deb) ...
> Unpacking replacement lmodern ...
> Setting up lmodern (1.00-3) ...
> Running mktexlsr. This may take some time... done.
> Running updmap-sys. This may take some time... done.
>
> [ Now, we have both 10lmodern.cfg and 20lmodern.cfg under
> /etc/texmf/updmap.d/... ]
>
> # ll /etc/texmf/updmap.d
> total 20
> -rw-r--r-- 1 root root 2787 2006-10-14 19:30 00updmap.cfg
> -rw-r--r-- 1 root root 1681 2006-10-07 23:16 10lmodern.cfg
> -rw-r--r-- 1 root root 2623 2006-07-20 12:59 10tetex-base.cfg
> -rw-r--r-- 1 root root 1681 2006-12-11 19:13 20lmodern.cfg
> -rw-r--r-- 1 root root 1314 2006-07-20 12:59 20tetex-extra.cfg
> # dpkg -P lmodern
> (Reading database ... 135647 files and directories currently installed.)
> Removing lmodern ...
> Running 'mktexlsr /usr/share/texmf /var/lib/texmf'.
> This may take some time... done.
> Running 'updmap-sys'.
> This may take some time... done.
> Purging configuration files for lmodern ...
>
> [ And even after purging, the old conffile 10lmodern.cfg from the
> official 1.00-3 version is left over. Baaad. ]
>
> # ll /etc/texmf/updmap.d
> total 16
> -rw-r--r-- 1 root root 2787 2006-10-14 19:30 00updmap.cfg
> -rw-r--r-- 1 root root 1681 2006-10-07 23:16 10lmodern.cfg
> -rw-r--r-- 1 root root 2623 2006-07-20 12:59 10tetex-base.cfg
> -rw-r--r-- 1 root root 1314 2006-07-20 12:59 20tetex-extra.cfg
>
> --
> Florent
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Thu, 01 Jan 2009 15:39:02 GMT) (full text, mbox, link).
Acknowledgement sent
to "Richard Hartmann" <richih.mailinglist@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Thu, 01 Jan 2009 15:39:02 GMT) (full text, mbox, link).
What's the status of this bug report? I am triaging Zsh
and this is blocking #349582
Thanks :)
Richard
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Tue, 08 Sep 2009 05:21:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Tue, 08 Sep 2009 05:21:03 GMT) (full text, mbox, link).
Subject: Re: Bug#108587: dpkg vanishing conffiles - more complex/complete
specification
Date: Tue, 8 Sep 2009 07:17:02 +0200
Hi!
On Thu, 2005-09-01 at 16:33:09 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: dpkg vanishing conffiles - more complex/complete specification"):
> > New scheme:
> > * During unpack, [...]
>
> I have implemented this and tested it and it works for me. It fixes
> the spurious conffile prompt I was seeing and appears to work
> otherwise.
> diff -ru orig/dpkg-1.13.11/src/remove.c dpkg-1.13.11/src/remove.c
> --- orig/dpkg-1.13.11/src/remove.c 2005-08-14 19:23:51.000000000 +0100
> +++ dpkg-1.13.11/src/remove.c 2005-09-01 12:50:29.000000000 +0100
> @@ -429,6 +429,11 @@
>
> for (conff= pkg->installed.conffiles; conff; conff= conff->next) {
> static struct varbuf fnvb, removevb;
> + if (conff->obsolete) {
> + debug(dbg_conffdetail, "removal_bulk conffile obsolete %s",
> + conff->name);
> + continue;
> + }
> varbufreset(&fnvb);
> r= conffderef(pkg, &fnvb, conff->name);
> debug(dbg_conffdetail, "removal_bulk conffile `%s' (= `%s')",
This ‘continue’ there makes the obsolete conffile not be removed on
purge. Pushing a fix for 1.15.5.
regards,
guillem
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Sun, 25 May 2014 08:48:09 GMT) (full text, mbox, link).
Acknowledgement sent
to <SammieMuldowneyu@gmx.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Sun, 25 May 2014 08:48:09 GMT) (full text, mbox, link).
Sehr geehrte/r Arbeitsuchender,
folgender Jobvorschlag ist für alle geeignet, da diese Arbeit ohne besondere Anforderungen auch von zu Hause zu bewerkstelligen ist. Der Arbeitnehmer hat keine Ausgaben und muss keine besonderen Kenntnisse mitbringen. Die benötigte technische Ausrüstung wird von uns kostenlos zur Verfügung gestellt. Zu Ihrem Arbeitsfeld gehört die Koordinierung, das Erstellen von Buchwerken, das Erstellen von Mediatheken, die Datendigitalisierung und die Vorbereitung der Dokumentenbearbeitung. Wir bieten eine attraktive Vergütung in Höhe von 17€ pro Stunde.
Unser Betrieb verfügt über viele Firmensitze auf der ganzen Welt und wir arbeiten im Onlinebereich. Zur Zeit suchen wir nach neuen Mitarbeitern.
Folgendes wird verlangt: Sie verfügen über ein Paar Stunden Zeit am Tag, Grundkenntnisse von MS-Office sind von Vorteil, eine Tätigkeit von zu Hause entspricht Ihrer Vorstellung, Sie besitzen Flexibilität, sie verfügen über ein Paar Stunden Zeit am Tag und Sie besitzen eine teamorientierte Arbeitsweise.
Haben wir Ihr Interesse geweckt? Dann freuen wir uns über Ihre Bewerbung! Senden Sie Ihre kompletten Bewerbungsbögen an: JuneNicholsono@gmx.com
Wir freuen uns auf Ihre Bewerbung.
Hochachtungsvoll
Roolking GmbH
Changed Bug title to 'dpkg: Conffiles that vanish across an upgrade can fool dpkg' from '[CONFFILE] dpkg: a conffile that vanishes across an upgrade can fool dpkg'
Request was from Guillem Jover <guillem@debian.org>
to control@bugs.debian.org.
(Sun, 29 Mar 2015 01:30:08 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Thu, 27 Oct 2016 22:03:02 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx International Next Flight" <david.krause@www2.csgw.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Thu, 27 Oct 2016 22:03:02 GMT) (full text, mbox, link).
Dear Customer,
Your parcel has arrived at October 26. Courier was unable to deliver the parcel to you.
Please, open email attachment to print shipment label.
Yours faithfully,
David Krause,
Operation Agent.
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Tue, 01 Nov 2016 18:15:05 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx International Ground" <henry.poole@antarvasnahd.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Tue, 01 Nov 2016 18:15:05 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Thu, 03 Nov 2016 21:45:05 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx Standard Overnight" <author@newsheadline.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Thu, 03 Nov 2016 21:45:05 GMT) (full text, mbox, link).
Hello,
We could not deliver your parcel. Please, download Delivery Label attached to this email.
Kendrick Cumens - Area Manager FedEx , CA
Kind regards
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Mon, 07 Nov 2016 19:30:06 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx International MailService" <alvin.oneil@achievors.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Mon, 07 Nov 2016 19:30:06 GMT) (full text, mbox, link).
Dear Customer,
Courier was unable to deliver the parcel to you.
Delivery Label is attached to this email.
Yours faithfully,
Alvin Oneil,
FedEx Delivery Manager.
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Mon, 14 Nov 2016 02:06:03 GMT) (full text, mbox, link).
Acknowledgement sent
to "FedEx 2Day A.M." <katherine.jardine@friendssfpl.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Mon, 14 Nov 2016 02:06:03 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Wed, 26 Jan 2022 15:57:02 GMT) (full text, mbox, link).
Acknowledgement sent
to dravasmith27@gmail.com:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Wed, 26 Jan 2022 15:57:02 GMT) (full text, mbox, link).
--
Hello Dear,
how are you today?hope you are fine
My name is Dr Ava Smith ,Am an English and French nationalities.
I will give you pictures and more details about me as soon as i hear from you
Thanks
Ava
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Fri, 25 Feb 2022 07:51:04 GMT) (full text, mbox, link).
Acknowledgement sent
to hari_kunda1@hotmail.fr:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Fri, 25 Feb 2022 07:51:04 GMT) (full text, mbox, link).
--
Greetings from Mr.Hary Kunda
How are you and your family?
There is a business deal I would like to introduce to you. There is no
risk involved.
The deal is worth $10.5 million. We split it in half - 50% each.
Revert to me asap if you are interested.
Regards,
Mr. Hary Kunda
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Mon, 21 Mar 2022 14:06:03 GMT) (full text, mbox, link).
Acknowledgement sent
to peacemaurice96@gmail.com:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Mon, 21 Mar 2022 14:06:03 GMT) (full text, mbox, link).
I also wrote you a previous message two days ago but no response from you,
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Wed, 07 Dec 2022 14:03:03 GMT) (full text, mbox, link).
Acknowledgement sent
to map8461@gmail.com:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Wed, 07 Dec 2022 14:03:03 GMT) (full text, mbox, link).
I also wrote you a previous message two days ago but no response from you,
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#108587; Package dpkg.
(Wed, 10 Apr 2024 08:03:08 GMT) (full text, mbox, link).
Acknowledgement sent
to info.claim_office78@realtyagent.com:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Wed, 10 Apr 2024 08:03:10 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.