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.
