Re: Init scripts as conffiles
On Tue, 15 Feb 2011 17:04:10 -0600
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote:
> On Tuesday 15 February 2011 16:44:49 Matt Zagrabelny wrote:
> > On Tue, Feb 15, 2011 at 4:39 PM, Joey Hess <joeyh@debian.org> wrote:
> > > Matt Zagrabelny wrote:
> > >> I understand the difference between remove and purge and the
> > >> reason to use both, but removing unmodified conf files seems
^^^^^^^^^^
> > >> like a win to me. Keeps the clutter down.
> > >
> > > You'll stop thinking this when apt decides to do an upgrade as
> > > follows:
> > >
> > > 1. remove foo (and its conffiles)
> > > 2. install bar
> > > 3. install foo
> > >
> > > That is one of the reasons for the current behavior, and
> > > temporarily removing a package is how apt deals with certian
> > > dependency issues. Renaming a package is another similar reason
> > > for the current behavior.
> >
> > 1. would remove the unmodified conf file
> > 3. would install it
> >
> > Did I miss something?
>
> It might be different and incompatible with the conffile(s) (if any)
> you did save. For example, it might no longer #include (or similar)
> the conffile that was saved.
I think you missed something ("unmodified").
> I would support a --purge-unchanged option, it seems like it could be
> useful in certain circumstances. However, something like that
> couldn't be the default for the same reason --purge can't be the
> default.
Purging only unchanged files is what we're asking for. If it's a
non-default option I'd be satisfied with that.
> I'm not sure how such a state would be representing in dpkg.
> uninstalled, half-configured?
Hm, good point. If it was marked "not-installed" would dpkg/apt still
avoid clobbering a previously installed conffile? If it was marked
"config-files" then dpkg/apt would need rewriting to make
--force-confmiss the default.
Reply to: