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

Re: Renaming a conffile in maintainer scripts



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 ?

> 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.

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)

> 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.

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont     -o- http://ddumont.wordpress.com/


Reply to: