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 decision. 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part