Re: How to use remove-on-upgrade to remove a configuration file?

[Niels Thykier <niels@thykier.net>]

Niels Thykier:
> Ludovic Rousseau:
>> Hello Niels,
>>
>> Le 08/08/2021 à 09:09, Niels Thykier a écrit :
>>> Ludovic Rousseau:
>>>> [...]
>>>
>>> Hi Ludovic,
>>>
>>> You cannot use that feature yet as it would break during upgrade. The
>>> dpkg version in stable does not support the feature.  Which is also why
>>> there is no debhelper feature to support it yet.
>>
>> OK. I was searching for something that does not (yet) exist :-)
>>
>> My plan was to upload the package in Bullseye +1 so after the (soon)
>> release of Bullseye.
>> Bullseye will then be the new stable and will have dpkg 1.20.9. So that
>> should work. No?
>>
>> Thanks
>>
> 
>>From an upgrade/low-level tech perspective, yes, it would work.
> 
>>From an "how do I use this feature" perspective, I would recommend that
> you/people wait until relevant wiring has been added to debhelper.
> 
> ~Niels
> 

Hi,

I just uploaded debhelper/13.5 that adds support for the new feature via
the following methods:

 * Use of "rm_conffile" in debian/<pkg>.maintscript will now be
   optimized into the "remove-on-upgrade" feature in cases where I
   believe I could do it safely and reliably.
   - This is easiest to use for most people; you can just keep doing
     what you have been doing and it will "just work(tm)".
   - This method also have the advantage that we can "roll it back"
     centrally if it turns out that some critical piece of
     infrastructure does not support the new vales in DEBIAN/conffiles.

 * debian/<pkg>.conffiles is now installed again in all compat levels
   for the case you want to use the feature directly.
   - This method provides the highest degree of freedom/control but you
     will in general want ensure you are using debhelper (>= 13.5~) and
     that is currently not available in -backports.

For bullseye, my recommendation would be to stick with "rm_conffile" in
debian/<pkg>.maintscripts.

Also note that DEBIAN/conffiles has been a list of files since
"forever".  Most likely some bits of code assumed this would never
change and we will probably see the effects of that soon.

Thanks,
~Niels