Re: Running cdebconf. Status and RFC
Just to let you know, I've done some work on it, had some real life stuff
to deal with, and hit some technical issue, but I believe I just found
what was my last blocking problem, so I'm now expecting to push a working
version during the weekend.
On Thu, October 6, 2011 16:30, Regis Boudin wrote:
> Hi Joey,
> On Thu, October 6, 2011 16:07, Joey Hess wrote:
>> Regis Boudin wrote:
>>> * debconf/frontend: debconf and cdebconf have different names for the
>>> frontends (Readline, Dialog, Gnome, versus text, newt, gtk), which
>>> all sorts of issues for the transition. Any objection to using
>>> cdebconf/frontend instead ?
>> Not really, but the rest of d-i would need to be checked for uses of it.
> That part should be fine, I can keep the existing checks for both the old
> and new fields.
>>> * When switching from debconf to cdebconf, there is the problem of the
>>> database. One uses /var/cache/debconf, the other /var/lib/cdebconf by
>>> default, meaning either it has to be migrated, or cdebconf will have to
>>> use /var/cache/debconf. The main issue of migrating the database is in
>>> the case of a system wide upgrade where cdebconf would actually replace
>>> debconf. Between the package being unpacked and the postinst script
>>> run, the database will be unconfigured ; so any other package trying to
>>> use debconf in this interval won't have access to the previously set
>>> values. This includes triggers, e.g. in the man-db postinst.
>>> Do you have any opinion in the long term ? In the short term, I could
>>> include the migration script for people willing to test, but I would
>>> someone else's view on it before I do it.
>> I can see no way around debconf and cdebconf using the same database,
>> perhaps a preinst would need to move it and set up a symlink so debconf
>> still sees it?
> That could actually be a solution. I'll try something along these lines,
> and make a new release with only the (c)debconf/frontend change in the
> Thanks for the answer and suggstion.