Re: r46016 - in trunk/packages/main-menu: . debian
On Fri, Mar 30, 2007 at 08:37:15PM +0200, Frans Pop wrote:
> On Friday 30 March 2007 19:55, Colin Watson wrote:
> > On Fri, Mar 23, 2007 at 01:50:14PM +0100, Frans Pop wrote:
> > > For example, if you want to change the mirror protocol, or setup the
> > > sudo for the target system, or not create a user account, you can
> > > currently just <Go Back> to the main menu, select the component again
> > > and you will have those options available.
> >
> > This always seemed like a non-intuitive Easter egg to me. Why not
> > explicitly change the priority using cdebconf-priority if that's what
> > you actually want? It's not clear to me that it ought to be the
> > default.
>
> Well, as long as #331679 is not fixed, that is very uncomfortable.
Yes, that needs to be fixed too. I'll see if I can figure something out.
Considering that this is all post-etch, I don't see that my change needs
to be immediately backed out on account of that other bug, though.
> > > Also, I don't really see the difference between selecting a component
> > > again straight away and first executing a different (no-op) component
> > > like Save debug logs, Check CD integrity or Start a debug shell
> > > before going back to the component.
> >
> > Perhaps neverdefault components ought to be special-cased here. I can
> > see that we perhaps ought not to return the priority to the default on
> > selecting them.
>
> Hmm. I would say that with this change, selecting a neverdefault component
> should not reset last_item_backup.
Done in r46103.
> Note that save-logs somehow already does that. I have no idea how though.
Accident, or confusion between this and some other behaviour? I don't
see any code that would do this either.
> > > IMO, the old behavior of only resetting the priority after successful
> > > completion of the next selected component was more useful.
> >
> > The next selected component might be quite long and involve many steps
> > of its own. What if it happens to be pkgsel, for instance?
>
> Are you suggesting we should disable that behavior altogether then?
Yes. I certainly don't think that "after successful completion of the
next selected component" is the right UI, considering what a "component"
can involve. I think the behaviour with my change is generally better
(modulo bugs like the ones you've mentioned), which is why I committed
it.
> BTW, is there really any reason to lower the priority below "medium" on
> errors? AFAIK we don't have any questions that add problem solving
> capacity at low priority and if a user really wants low priority he can
> always select "Change debconf priority". The main thing is to display the
> menu on errors. IMO the logic could be changed to:
> on error, if priority > medium, then priority == medium
The original reason for lowering it further is because doing so might
expose UI that lets you get around the error. If your belief that there
are no such questions is correct then it would indeed be unnecessary,
but since that was the original assumption I think you would need to
carefully verify that belief first.
--
Colin Watson [cjwatson@debian.org]
Reply to: