[Piuparts-devel] changed severity
Daniel Pocock
daniel at pocock.pro
Wed Jul 27 20:25:24 UTC 2016
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.
More information about the Piuparts-devel
mailing list