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

Bug#666530: cups fails to configure under cdebconf



Ok,

I've modified cdebconf, so trying to get a flag that doesn't exist now
returns false instead of an error, which is more consistent with the
original debconf behaviour, though it's still not possible to set
arbitrary flags.

Regis

On Sat, 2012-03-31 at 23:24 +0100, Regis Boudin wrote:
> Hi,
> 
> Thanks for the report,
> 
> On Sat, 2012-03-31 at 10:19 -0400, Jacob Emmert-Aronson wrote:
> > Package: cdebconf
> > Version: 0.160
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > When cdebconf is enabled,
> 
> Oh, one more person running cdebconf ! It's getting a bit popular.
> 
> >  the cups postinst script dies with exit
> > status 15 (confirmed against cups versions 1.5.2-5, 1.5.2-8, and
> > 1.5.2-9).  Unsetting DEBCONF_USE_CDEBCONF to fall back to debconf
> > allows the package to install correctly.  I locally repackaged cups
> > to add "set -x" to the postinst script and obtained the following
> > output, which may be useful in debugging:
> > 
> > > + db_fget cupsys/raw-print changed
> > > + _db_cmd 'FGET cupsys/raw-print' changed
> 
> There it is. 'changed' is not a known/defined flag, so cdebconf returns
> an error message. Debconf on the other hand can take any string as a
> flag, so returns "0 false".
> 
> > My apologies if this would be more appropriately filed under the cups
> > package; feel free to reassign if that is the case.
> 
> Well, you've found a difference between debconf and cdebconf, so it's
> good to raise it here anyway.
> 
> I guess this mostly brings the question of the flags management
> difference between Debconf and cdebconf. The former can take any word,
> while the latter can only take predefined ones by design, since they are
> stored internally as a bits field. Should we :
>  * keep the internal cdebconf design, and restrict debconf flags to a
> list of defined ones (seen, dontparse, changed, ?)
>  * make cdebconf as flexible of debconf, which would probably involve a
> change of the libdebconf API and ABI.
>  * Another solution I might not think about right now.
> 
> Regis
> 
> 
> 
> 





Reply to: