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 <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
