[Pkg-roundcube-maintainers] Bug#478170: roundcube: files missing after install

[Vincent Bernat]

OoO Pendant le journal télévisé du dimanche 04 juillet 2010, vers 20:21,
Luca Capello <luca at pca.it> disait :

>> However, I  cannot just simply drop  them from the  package because some
>> people  installed earlier  version  of roundcube  package  and may  have
>> modified /etc/default/roundcube.  They should be aware  that the content
>> of it has moved to /etc/default/roundcube-core and I cannot do it myself
>> because a package  do not have the right to mess  with files modified by
>> the user. This is why roundcube ships an empty (with comments) file.

> And this is completely wrong, you should instead move them as explained
> in the Debian wiki <http://wiki.debian.org/DpkgConffileHandling> or,
> better, through dpkg-maintscript-helper (included in dpkg >= 1.15.7.2).

I  need to  move  a conffile  from  one package  (roundcube) to  another
(roundcube-core). It  is not clear  that dpkg-maintscript-helper handles
this situation.

>   When a package is installed for the first time dpkg will install the
>   file that comes with it, unless that would mean overwriting a file
>   already on the file system.

>   However, note that dpkg will not replace a conffile that was removed
>   by the user (or by a script). This is necessary because with some
>   programs a missing file produces an effect hard or impossible to
>   achieve in another way, so that a missing file needs to be kept that
>   way if the user did it.

>   Note that a package should not modify a dpkg-handled conffile in its
>   maintainer scripts. Doing this will lead to dpkg giving the user
>   confusing and possibly dangerous options for conffile update when the
>   package is upgraded.

>   http://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html#sE.1

> In roundcube's postinst, you are exactly doing what you should not:
> modifing a dpkg-handled conffile, bug severity raised to normal (not
> serious because the Debian Policy extract above is a "should" and not a
> "must" nor a "required").

I  don't modify a  dpkg-handled conffile.  I ship  a new  conffile whose
content should hint  the user that she should  move any modifications to
the new file if she has modified the previous conffile and I deleted the
old conffile if it was unmodified.

I don't use md5sum like what is  done in the wiki, but I let dpkg handle
the replacement of the old conffile with a dummy conffile and prompt the
user  to accept this  modification if  the user  modified this  file and
remove the file only if I find the dummy conffile intact.

This seems very similar to what is  done in the wiki except that I don't
move automatically the user changes from one conffile to another.

Let me  go through an example. If  you have an old  version of roundcube
package, you  get /etc/default/roundcube. I  want to move  this conffile
From    roundcube    to   roundcube-core    and    its   name    becomes
/etc/default/roundcube-core.  I  ship  a new  /etc/default/roundcube  as
conffile whose  content is "#  Content of this  file should be  moved to
roundcube-core, blah, blah".

If the  user did  not modify the  conffile, it  will be replaced  by the
dummy content. In postinst, I will  see that the content of the conffile
is the dummy one and I will just delete the file.

If the user did  modify the conffile, dpkg will ask her  what to do. The
user will see the content of  the new conffile (the dummy content) which
contains instructions.  She can  abort the installation,  copy/paste the
modifications   or  take   any  appropriate   actions   including  doing
nothing. If she  does nothing, the old conffile  content is not replaced
by  the dummy content  and the  file is  not erased.  If she  copies the
content of the  old conffile to the new one and  accept the changes, the
old conffile will be removed.

I would  like to adopt dpkg-maintscript-helper  way to do,  but it seems
that this  does not work  when a conffile  is moved from one  package to
another.
-- 
printk("Entering UltraSMPenguin Mode...\n");
	2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-roundcube-maintainers/attachments/20100710/c3f3d2c3/attachment.pgp>