[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] added --force-* options for conffile handling

On Mon, Oct 11, 1999 at 05:10:10PM +0100, Jules Bean wrote:
> On Mon, 11 Oct 1999, Daniel Burrows wrote:
> > On Mon, Oct 11, 1999 at 11:37:05AM -0400, Ben Collins was heard to say:
> > 
> >   Hm.  While you're fixing things up, could you add an option to display a diff
> > of <conffile> and <conffile>.dpkg-new, and an option to mail the administrator
> > with a list of the conffile changes that might need to be merged? (possibly
> > containing these diffs)  See bug #40650 .
> And, since the subject has come up, even better, run diff on
> <cf>.dpkg-dist and <cf>.dpkg-new, and merge (perhaps using merge(1)) them
> into the new conffile.
> However, I've never quite satisfied myself that I understand if the
> .dpkg-dist file is always there.  (It seems to always be there when I want
> it..).

I've actually had a better notion which involves a version tag in the conffile.

The version number increases based on the importance of the change. For example
given these three conffiles from three package revisions.

	# conffile for foo-1.0-1
	option_a = 2
	# This is an option

	# conffile for foo-1.0-2
	option_a = 2
	# This is the only option

	# conffile for foo-1.0-3
	option_a = 10
	# This is the only option

Now notice between -1 and -2 we only had a simple change in the comment. No
one wants to really upgrade the conffile just for this (unless it's an important
comment), so we only increase the minor most version digit. Now from -2 to -3,
we actually changed the default of the option. Depending on the option/package,
this might be fairly important, so we increase a more significant digit in the
conffile version.

IOW, the conffiles would be rated in the importance similar to how changes in our
policy document are. Policy would have to rate each version digit and explain its
importance level for maintainers to reference. Also a sane decision has to be
made when going from non-versioned to versioned, and also for when the admin
removes the version (by mistake, or intentionally, or even changes it manually).

Also, how the user is presented this information (aswell as how they can give a
default threshold for promptless upgrades) would need some hammering out.


Reply to: