Bug#825121: changed severity

[Daniel Pocock]

On 27/07/16 14:15, Andreas Beckmann wrote:
> On 2016-07-27 11:08, Daniel Pocock wrote:
>>
>>
>> I looked at the piuparts log:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=825121;filename=sipdialer_1%3A1.10.2-1.log.gz;msg=5
>>
>> and it confirms that the freeradius-client package was installed before
>> the radcli package, therefore, the preinst script tries to migrate the
>> configs.  This is expected behavior.
> 
> Getting a dpkg conffile prompt is *not* expected behavior if the config
> file was not modified by the local admin.
> Migrating the conffile cannot be done in the preinst alone.
> 
>> I've downgraded the severity in case anybody wants to discuss it
>> further, otherwise this bug can potentially be closed.
> 
> So what you are trying to do is to
> a) rename a conffile and

They are copied, not renamed

The original conffiles remain associated with the freeradius-client
package and when nothing else on the system depends on freeradius-client
any more, those conffiles can be removed with it.

> b) change its ownership to a different package
> at the same time. That is unfortunately not well supported by the
> current tools (e.g. dpkg-maintscript-helper).
> 

The radcli package keeps its conffiles in /etc/radcli


> We had some more packages doing this, but right now I only remember
> initramfs-tools (has a bug and a patch by me). Cc:ed Holger in case he
> remembers some more.
> 

If there is a feature request to improve support for this situation,
should this bug be linked to it?


> Is the config file shipped by the old and new packages the same (as in
> "bytewise identical")? Would that be possible?
> 

No, that is not the case.  Newer versions of radcli will probably add
more things to these files too although as it is a fork, it is able to
read everything in the original freeradius-client config files.

freeradius-client won't exist in stretch, it has been removed from the
archive, but the package may linger on some systems.  Newer versions of
radcli will appear through backports and/or security updates and they
may bring in more changes to the conffile too.

One alternative strategy would involve asking upstream to stop
maintaining a fork (radcli) and merge all changes into
freeradius-client.  They are meant to be API and ABI compatible anyway.