conffiles, newer packages and purging

Earlier this month Kumar Appaiah opened a bug against the culmus package as part of the stable -> unstable piuparts upgrade tests.

First, I’m proud in Debian to have these tests. Thanks for the people involved with running them, parsing the log files and reporting the bugs. I really feel the lake of such checks in commercial distributions I work with.

After finding the time to get to the bottom of the bug, and talking with Kumar, it seems most of the bugs found in the test are similar. I think this might indicate something wrong in a more basic level of the package handling.

The source of these bugs is how to handle files which were conffile in version x, but aren’t included in version x+1 (as a regular file). In the common situation, the conffiles are removed only during the purge process and not during upgrade or removal. But if a conffile doesn’t exist in the x+1 package, no one will “own” it after the upgrade, and no will purge it in due time.

This is why changing conffiles can result in extra files on our system, which is the problem discovered by the recent piuparts test.

One solution will be that each package maintainer will add the necessary code to the maintainer scripts to remove the file on upgrade. A second solution is to decide the wanted behavior in such a case and to have dpkg handle it for all packages.

The behavior can be to remove the old conffile during the upgrade (postinst script) or to dynamically add it to the list of files owned by the package. Although technically possible, I’m not sure if the second method is “legal” with the debian policy.

I thought it would be better to hear others’ opinions before submitting a wishlist bug about this.

3 Comments

Filed under Debian GNU/Linux

3 responses to “conffiles, newer packages and purging

  1. Dear Lior,

    Many thanks for the blog post.

    I would also like to point out this relevant bug report which you mention in the post with reference to dpkg.

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454628

    Thanks.

    Kumar

  2. Olaf van der Spek

    > One solution will be that each package maintainer will add the necessary code to the maintainer scripts to remove the file on upgrade.

    Code duplication doesn’t seem like a good thing.
    Just removing the file doesn’t seem like a good thing either.
    The files should be tracked such that the user can easily remove them later.
    I think the same should happen to files of packages that were removed instead of purged.

  3. As Kumar pointed, there’s already a bug report about this. So no need to open a new one. However a patch would be great. The C code of dpkg is not the part that I like to hack very much…🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s