Bug#108587: May packages rm -rf subdirectories of /etc/ ?
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
> 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).
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.
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