Re: PW#5-3: How packages can register cron jobs
On Mon, 2 Feb 1998, Ian Jackson wrote:
> Brian White:
> [ Kai: ]
> > > We should also correct the policy to say that _no_ package should touch
> > > _any_ config file from a script. The problem caused that way isn't related
> > > to which package script and config file belong to.
> >
> > While a good general rule, I think it would be a mistake to make it
> > all encompasing. There will be cases where touching the conffile
> > within the postinst of another package really will be the best way to
> > do things.
>
> If I am not mistaken it is already prohibited to modify a dpkg-handled
> conffile from a script at all (which is the required condition).
>
> If this restriction has been removed it needs to be replaced. If not
> then it clearly needs to me made more prominent.
That's already documented in the Packaging Manual 1.4.0.20, section 9.1:
``Note that a package should not modify a dpkg-handled conffile in its
maintainer scripts. Doing this will lead to dpkg giving the user
confusing and possibly dangerous options for conffile update when the
package is upgraded.''
I think we should add a new section that explains how to handle the case
where a script has to modify a `conffile.'
Is the following solution correct?
1. The `conffile' is _not_ tagged as conffile and _not_ included in the
package tree,
2. it's created in the postinst script if that file does not already
exist,
3. it's removed in the postrm script when a `purge' is selected.
But then, how should we handle the cases where the `configuration file'
exists already, before the package was installed? Should we leave this
file as is and should the postrm really remove that file when a `purge'
was selected?
In addition, I think the corresponding section of the Policy Manual also
needs to be corrected. Currently, section 3.3.7 Configuration files reads
``[...] It is almost certain that any file in /etc that is in your
package's filesystem archive should be listed in dpkg's conffiles control
area file. (See the Debian Packaging Manual).
Only packages that are tagged conflicting with each other may specify the
same file as conffile. A package may not modify a configuration file of
another package. [...]''
Obviously, the first section I quoted has to be changed, since we'll get a
lot of files in /etc which are not marked as conffiles anymore.
In addition, we might get another problem: Currently, policy forbids that
two packages install the same `conffile'. This can be verified easily by
scripts (e.g., via lintian). But if conffiles are not marked as
`conffiles' anymore, this will be nearly impossible.
Wouldn't it be good to list such `configuration files' (that need to be
changed by scripts) in a new control field?
Thanks,
Chris
-- Christian Schwarz
Do you know schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian GNU/Linux? schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/
Reply to: