Re: Configuration file update behaviour change options
Richard Kettlewell <firstname.lastname@example.org> said:
> >Is it perhaps sufficient to give the package maintainer the
> >ability to change these options, but not the package installer;
> >putting the package maintainer in control of conffile handling
> I don't think that's the right way to do it. As an installer I'd want
> to be able to specify that e.g. no configuration files should be
> overwritten (if I believed I knew what I was doing) - a package
> maintainer can't know whether local edits are of the kind that need to
> propogate across reinstallation.
Unless they've been looking in /var/lib/dpkg/status, package
installers won't know what files in a package are conffiles and what
are not. Package maintainers do know about such things.
Also, an installer won't know what the conffile setup of an
uninstalled upgrade package is, unless there are release notes
or somesuch to tell him, and we don't make any provision for package
release notes. It's likely pretty close to the installed version
which he's upgrading -- but perhaps not.
If this isn't made a maintainer option instead of an installer option, how
about making it a maintainer option as well as an installer option.
There'd be a default, which could be overridden by the maintainer, which
could be further overridden by the installer.
Also, how about making this a file-by-file selection, instead of
applying it to all conffiles in a pakcage.
> >If so, non-default handling behavior could be specified in the
> >control file or conffiles file if different from the default
> >(I'd suggest extending the conffiles syntax to cover this).
> Did you have an example in mind of where it's important that the
> maintainer be able to control conffile update behaviour as opposed to
> the installer?
I'd argue that the default behavior should be to install conffiles
which are found to have been deleted -- to follow the principle of
least suprise. Inadvertantly delete a file from the xyz package?
Reinstall the package. (Note -- the normal user won't know a file
which the package has identified as a conffile from one which it
Ian Jackson has pointed out, though, that some packages attach
significance to a conffile being missing, and that a deleted
conffile might be a normal case which should be preserved through
an upgrade. For these packages, it would probably be appropriate
for the package maintainer to override the least-suprise behavior
I advocate above. This would provide that maintainer with a way
to do this.