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

Re: cdebconf-entropy plugin: usage, templates and strings

Hey Jérémy,

On Thu, Mar 06, 2008 at 01:44:45PM +0100, Jérémy Bobbio wrote:
> The first plugin to be written, obviously, is the graphical sibling to
> the plugin gathering entropy, used in partman-crypto.  The code for this
> plugin was actually written while working on the rest of the GTK+
> frontend [1] but as yet to be integrated properly.
> [1] http://people.debian.org/~lunar/fe_gtk-plugin-entropy.c

Thanks for your work on this! 

The implementation looks fine from a quick glance. Please 
feel free to add integrate it into cdebconf-entropy when
you are happy with it.

> I think it would make more sense to make a single question type, for
> both frontend, named "entropy", and to have a single question template
> in partman-crypto and a single code path handling both frontends.

> I thought about using the newly introduced debconf directives, but I
> might just wanna play with a new toy here.  So I really want to know
> other advices before hacking…  Here is the proposed implementation,
> though:
> Using directives would make the previous template look like:
>   _Description: ${!ENTROPY_SHORT_TITLE}
>    The encryption key for ${DEVICE} is now being created.
>    .
> A new text template would be introduced in each plugin built by
> cdebconf-entropy.  Its short description would be used for
> description.

The approach sounds fine.

I'm not familiar with the new debconf directive mechanism.
Is there any documentation I could look at? Any pointers 
would be appreciated. :-)

If directives weren't available, I would probably have 
gone for a similar but slightly diffent solution - we could
have partman-crypto provide a description fragment

  _Description: The encryption key for ${DEVICE} is now being created.

The different 'entropy' type frontend plugins would take
the fragment and integrate it with the appropriate frontend-
specific text to form a complete dialog. 

IOW, if directives are a good fit for this use, I see no
reason to not go ahead with the proposal you outlined.


Reply to: