Re: Renaming a conffile in maintainer scripts
Hi,
On Mon, 11 Oct 2010, Dominique Dumont wrote:
> On Friday 08 October 2010 15:38:22 Raphael Hertzog wrote:
> > While this avoids the conffile prompt in all cases, it also means that if
> > the new conffiguration file has changes compared to the old one, the user
> > doesn't get to see them... instead they are stored in .dpkg-new without
> > any prompt.
>
> Which brings the question: how can we be sure that the user should not be
> notified of configuration changes introduced by the package maintainer ?
The current logic used by dpkg is that the user should always be asked
when he modified the conffile, otherwise he's not asked on the basis that
the new default configuration file is a logical continuation of the
previous version.
This logic is not fully respected by the current dpkg-maintscript-helper
implementation of mv_conffile (hence my mail).
But I'm not sure I understood your question.
> > BTW, .dpkg-new is an extension used by dpkg to unpack new versions of
> > files during dpkg --unpack. So it will be automatically removed in the
> > next upgrade of that package... because the hash of the distributed file
> > has not changed and hence it believes that nothing needs to be done.
> >
> > At the very least, I think we should move <new> in <new>.dpkg-dist to be
> > consistent with what dpkg would have done if the user had seen a prompt
> > and answered to keep his old file. Do you agree with this?
>
> Currently, *.dpkg-dist means that some changes happened that were important
> enough to trigger a prompt. If they cannot be distinguished from *.dpkg-new,
> sys admin will not be able to focus on more important changes.
We have 2 cases when the old installed conffile was user modified:
- the renamed conffile is different from the old one
- the renamed conffile is the same than the old one
The first one is a case of "some changes happened that were important
enough to trigger a prompt" but we don't get a .dpkg-dist when we really
should. Worse, the unmodified conffile is lost on the next upgrade and the
admin can never merge the changes manually (or even noticing the need to
merge something).
The second one is fine as is admittedly. But changing the extension doesn't
hurt either IMO. It would be the same than using --force-confask and
selecting to keep the old conffile. A spurious .dpkg-dist is left around
but it represents the real unmodified default conffile.
That's why I was suggesting to use .dpkg-dist here.
> May be we'd need to distinguish - after upgrades - new conf files with
> important changes from new conf files with trivial changes (e.g. comments)
That's completely unrelated to my question, I'm afraid.
> > But can we do better and somehow find out the hash on the new conffile
> > during the preinst (inspecting /var/lib/dpkg/info/tmp.ci/ maybe?) so that
> > we can put the old conffile in place of the new when we know that it would
> > have resulted in a prompt anyway?
>
> Sorry, you lost me there.
Solving the above problem properly is doable if I can programmatically
distinguish between the 2 cases (renamed conffile is the same than the old one,
or not).
I was suggesting that it might be doable by inspecting
/var/lib/dpkg/info/tmp.ci/ where dpkg unpacks the control information of the package to
be unpacked (I only need to check the "conffiles" file there). Since
dpkg-maintscript-helper is provided by dpkg, we could afford to rely on
this even if it's not part of a public dpkg interface...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: