iEYEARECAAYFAjt3YiEACgkQ6kxmHytGonx7mwCfRSBdl2NHDSG5B4QrQZ0X5b1n PK8AniXFtvdx6FneNB+blI+22lcPDI5A =UIiQ -----END PGP SIGNATURE----- ----- End forwarded message -----
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).
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
Previously root wrote: Can you reproduce that? Wichert.
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:
and asks
Can you reproduce that?
Wichert.
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:
and asks
Can you reproduce that?
Wichert.
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
Jerry Quinn <jlquinn@optonline.net> cum veritate scripsit: It is modified in tetex postinst. This is a bug in tetex.
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.
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.
Herbert Xu <herbert@gondor.apana.org.au> wrote (to debian-devel): 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.
Previously Thomas Hood wrote: 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.
Herbert Xu <herbert@gondor.apana.org.au> wrote (to debian-devel): 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.
Previously Thomas Hood wrote: 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.
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". Yes. 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.
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". Yes. 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.
Previously Thomas Hood wrote: 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. 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.
Previously Thomas Hood wrote: 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. 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.
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.
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.
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.
Previously Branden Robinson wrote: I'll see if I can work that into the new conffile handling code. Wichert.
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)
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 Hood (jdthood@yahoo.co.uk) wrote: 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
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.
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?
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
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.
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.
Ian Jackson writes ("dpkg vanishing conffiles - more complex/complete specification"):
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.
Ian Jackson writes ("Re: dpkg vanishing conffiles - more complex/complete specification"):
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 writes ("Re: Bug#108587: dpkg vanishing conffiles - more complex/complete specification"):
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.
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:
What's the status of this bug report? I am triaging Zsh and this is blocking #349582 Thanks :) Richard
Hi! This ‘continue’ there makes the obsolete conffile not be removed on purge. Pushing a fix for 1.15.5. regards, guillem
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
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.
Dear Customer, We could not deliver your parcel. Shipment Label is attached to email. Yours faithfully, Henry Poole, Delivery Agent.
Hello, We could not deliver your parcel. Please, download Delivery Label attached to this email. Kendrick Cumens - Area Manager FedEx , CA Kind regards
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.
Hello, We could not deliver your parcel. Delivery Label is attached to this email. Fatima Handley - Area Manager FedEx , CA Sincerely
-- 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
-- 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
I also wrote you a previous message two days ago but no response from you,
I also wrote you a previous message two days ago but no response from you,