Re: Policy on configuration files(Re: Moving conffiles)
On Fri, Jan 17, 2003 at 11:26:01AM +0900, Atsuhito Kohda wrote:
> For a configuration file which is very deeply system related
> and sufficiently stable, it might be possible to satify the
> current policy on configuration files but I suspect there are
> many cases where an enhancement of an upstream completely changes
> configuration files (format, filename, etc.), especially in user
> application programs and it is very difficult to satisfy the
> current policy.
What exactly is the problem that current policy creates? This isn't
something that's new - for example, bind and inn have gone through this
sort of transition. Usually what's done is to warn the user in preinst
and give them a chance to abort the upgrade then install a default
configuration in the new style, keeping the old configuration files
somewhere. The user is then responsible for updating any changes they
made.
> I feel that the current policy prevents sane advance of
> packages. At least I have an impression that policy condition
> on configuration files should be splitted into ones which are
> system relevant and must (and could) preserve user's modifications
> strictly and others which admit more flexible treatment.
Note that policy only requires that you don't trash the modifications
users have made to the configuration file. It does not require that the
package actually work after the upgrade. If the user had to make the
modifications in the first place it's reasonable to expect them to do
the updates.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Reply to: