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

Re: Change the format of /usr/share/bug/*/script

On Thu, 2008-09-11 at 15:35 +0200, Josselin Mouette wrote:
> Le jeudi 11 septembre 2008 à 14:39 +0200, Luca Bruno a écrit :
> > The proposal:
> > I know it's bad to break compatibility but I also think keeping things
> > with hacks and far from the GUI prospective can become obsolete and
> > non user-friendly.
> > 
> > First solution: change the scripts to use a bash function instead of
> > cat <<EOF, like yesno() create a function display() without hacking
> > cat() and keep going using a FIFO to deal with the UI

I can't speak for others but my scripts use yesno():
  yesno "May I include your sources.list (/etc/apt/sources.list)? " yep

The frontend could execute their own shell wrapper that implements yesno
and sources the bug script (as reportbug does). The other yesno function
can do whatever is necessary to callback into the frontend, get the user
response and feed it back to the script.

If the frontend can use yesno(), I think it's perfectly reasonable to
expect all packages using bug scripts to use yesno() and not cat <<EOF.

> > Second solution: I don't know, I'm asking to you
> The second solution is to specify that these scripts should not be
> interactive. I don’t think there is much point in it, and it would
> simplify things a lot.

We've been here before. Some people might value the opportunity to
refuse permission to include sources lists and other data - any
non-interactive frontend must make it absolutely clear that this data
has been included and it is up to the user to delete it.

Cannot the other frontends do what reportbug does and implement a bash
function that scripts can call? The terminal can be hidden or run via
internal calls, just as long as it pauses and allows the user to make a

I suspect the problem with using debconf will be that debconf a) expects
to be run as root and b) is too specialised in how it wants to store
data (which we don't want to do at this point). However, something that
implements a choice of frontends *without losing functionality* is the
best bet.


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: