[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR] qcumber 2.3.0-2 and piuparts issues



On Sun, Jan 10, 2021 at 11:57:11PM +0100, Étienne Mollier wrote:
> Hi all,
> 
> I've been trying to address piuparts errors preventing qcumber
> to migrate to Testing.  After having spent some time trying to
> understand what piuparts was trying to tell me, it turned out
> there was an issue with the handling of the configuration file
> /etc/qcumber/config.txt, which in new installations of qcumber
> 2.3.0-1 ends up containing a second line wrong:
> 
> 	[DEFAULT]
> 	kraken_db = kraken_db =
> 	adapter = /usr/share/trimmomatic
> 
> Current changes I pushed to Salsa as an hypothetical qcumber
> version 2.3.0-2 allow installation of a default configuration
> with what seems to me the proper default value:
> 
> 	[DEFAULT]
> 	kraken_db = /var/lib/kraken/minikraken_20141208
> 	adapter = /usr/share/trimmomatic
> 
> However, the piuparts upgrade test fails when using qcumber
> 2.3.0-1 as a starting point due to the modified configuration
> file interface poping up:
> 
>   Configuration file '/etc/qcumber/config.txt'
>    ==> Modified (by you or by a script) since installation.
>    ==> Package distributor has shipped an updated version.
>      What would you like to do about it ?  Your options are:
>       Y or I  : install the package maintainer's version
>       N or O  : keep your currently-installed version
>         D     : show the differences between the versions
>         Z     : start a shell to examine the situation
>    The default action is to keep your current version.
>   *** config.txt (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package qcumber (--configure):
>    end of file on stdin at conffile prompt

I guess my postinst hack to edit the config file is responsible for that
trouble. :-(
 
> I tried to fix this issue, but this involved adding a preinst
> script which would mangle the existing configuration file to put
> back the default value.  But I believe this issue may not be
> blocking, as this behavior could easily go against the Debian
> policy section 10.7.3:
> 
> > local changes must be preserved during a package upgrade
> 
> My current idea would be to upload without the preinst mangling,
> hope this is sufficient, and if not then append the preinst.
> But maybe someone with more experience have better insights on
> that category of problems?

I admit I have no good insight into this kind of problems. :-(

> In any case, changes are available
> for review Salsa:
> 
> 	https://salsa.debian.org/med-team/qcumber
> 
> Note if you wish to try by yourself, fontconfig is currently
> preventing the piuparts purge test to work properly, so you may
> need to use `piuparts --warn-on-leftovers-after-purge ...`.
> 
> Please consider upload or DM grant if, in spite of the issues at
> play, you feel appropriate.

Granted and good luck that this will work out as expected.

Kind regards

      Andreas.



-- 
http://fam-tille.de


Reply to: