Plans for 11.4
Atri
yast2-gtk in 11.3 has been great! Thanks to Ricardo for doing so much
work, not to mention patiently replying/asking/explaining everything
on the mailing list!
The roadmap for 11.4 is here http://www.suse.de/~coolo/opensuse_11.4/
Are there some great new plans for yast2-gtk in store ;) ? Anyway, let
us start brainstorming ideas about what we can reasonably achieve by
March 2011. First we should perhaps tackle the issue of the
downgrading packages and the versions box pointed out here
[https://bugzilla.novell.com/show_bug.cgi?id=620513]
--
I was thinking if it might be possible to create a new "application"
view for the interface. Please note I am only using the term
application for the lack of something better, and it is not to be
confused with the general understanding of what an application means.
This would mean that the main package listing would not show lib*
files [which are supposed to be automatically pulled in], files that
extend packages [for example nautilus-terminal is not really an
application] and so on. In fact strictly speaking an application would
be something that [this might be too narrow a view]
- is a complete working software for a user
-- example: nautilus is an application, gstreamer-0_10 is not
- *must* provide a binary executable [in /usr/bin]
- usually provides a .desktop file in /usr/share/applications/ for a
menu item
- has appropriate doc entries [man pages, etc.]
I don't know if such a separation can be achieved within the scope of
present limitations though. It might be possible to look for files
provided by an rpm, though I see that at present this is done only for
installed files.
In the big picture, it might be nice to have the following
separation:-
- applications [as above],
- extensions [e.g. nautilus-terminal, etc.],
- libraries & backends [gstreamer, libgnome, etc.],
- devel packages [*-devel],
- debuginfo [*-debuginfo], and
- language extensions [*-lang].
Users can be shown just the applications by default. This will have
the following enhancements over the present method:-
- Present list of packages, even if broken into categories, is far too
long and there is *no* way a user can browse and discover packages.
Yes he can search if he already knows the name, which is what we
always do with the present implementation
- User sees an application, installs it -> it appears on his menu! He
should not have to even know about backends and libraries that are
required to make his application work.
Prototype for proposal [by Pavol Rusnak] http://gamestore.gk2.sk/
I guess this is rather too big a wish of mine, but boy if it were
possible to implement it!
Bye!
Ricardo Cruz
We could discuss improvements for parts of the software manager,
such as the mentioned versions-picking widget, but I'd be pretty adamant
against ambitious changes unless there are clear and major benefits.
One possible exception would be a merger of the qt and gtk
software managers (and possibly a partial ncurses one). It sounds
like it could be a pretty fun project of re-factorization, both code and UI
wise.
Anyhow, from what I can gather, webyast is being developed at a
rapid pace, and the looks of it seem extremely pleasant. oldyast might
very well be passé a year from now.
> Prototype for proposal [by Pavol Rusnak] http://gamestore.gk2.sk/
Ubuntu has something very much like that, and indeed it would be a
nice addition to opensuse.
The screenshot is the one feature I most miss most from Ubuntu. I
think it would also be nice to be able to sort software by user rating, or
download counts, otherwise you can easily get lost in the sea of applications
available within each category.
Before we consider whether users would be better served through
two different apps, or if a single one can cope with them all, there are
some basic features that will need to be added to the repository
databases.
By the way, it would be cool for such a program to be pluggable to
other online repositories of software, like mame games or, my personal
favorite, old dos games: http://www.abandonia.com/ .
Cheers,
Ricardo
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
C
> One possible exception would be a merger of the qt and gtk
> software managers (and possibly a partial ncurses one). It sounds
> like it could be a pretty fun project of re-factorization, both code and UI
> wise.
This would be really interesting to me. There are strong and weak
points in both tools... it'd be nice if we could somehow find/pick the
best of both... no idea how that could be done right now... but..
C.
Atri
> best of both... no idea how that could be done right now... but..
>
>
development seems to be only in bug-fixes and incremental updates mode
for last couple of releases. Would be happy to learn otherwise, but
the m-l archives [http://lists.opensuse.org/yast-devel/] don't show
much. Also since Katarina moved to OOo, nobody from yast-qt asks for
user-feedback for enhancements any more. So I guess we can assume that
this won't happen any time soon :(
--
Atri
Ricardo Cruz
Sounds like Novell is being rational.
You'll notice how in a party (a wedding reception, say), the tastier
the snack, the sooner they will be hunted to death. If you arrive late,
you'll be eating bread instead of sushi.
Novell also has a menu choose from, a menu of projects. Naturally, as
they hunt critical features and bugs in yast2, then the critical features
and bugs of openoffice will look like they will provide material for faster
and tastier killing sprees.
Novell is only a faithful servant of the almighty law of diminishing
returns, and Katarina the trusted executor.
But actually the mailing list shows a lot of activity in webyast. I think
most oldyast developers are working in that project, so it makes less
and less sense to invest in a player when you intend to introduce a
competitor a couple of releases later.
Cheers,
Ricardo
Quoting Atri <badsh...@gmail.com>:
Ricardo Cruz
When reading my message, please mentally introduce smileys
throughout. ;)
Ricardo
Quoting "Ricardo Cruz" <rpm...@alunos.dcc.fc.up.pt>:
> Hi Atri,
>
> Sounds like Novell is being rational.
>
> You'll notice how in a party (a wedding reception, say), the tastier
> the snack, the sooner they will be hunted to death. If you arrive late,
> you'll be eating bread instead of sushi.
>
> Novell also has a menu choose from, a menu of projects. Naturally, as
> they hunt critical features and bugs in yast2, then the critical features
> and bugs of openoffice will look like they will provide material for faster
> and tastier killing sprees.
>
> Novell is only a faithful servant of the almighty law of diminishing
> returns, and Katarina the trusted executor.
>
> But actually the mailing list shows a lot of activity in webyast. I think
> most oldyast developers are working in that project, so it makes less
> and less sense to invest in a player when you intend to introduce a
> competitor a couple of releases later.
>
> Cheers,
> Ricardo
>
----------------------------------------------------------------
Katarina Machalkova
> Novell also has a menu choose from, a menu of projects. Naturally, as
> they hunt critical features and bugs in yast2, then the critical features
> and bugs of openoffice will look like they will provide material for faster
> and tastier killing sprees.
>
> Novell is only a faithful servant of the almighty law of diminishing
> returns, and Katarina the trusted executor.
Wow, now I learn interesting things about myself :))) Let me shed some light
into this.
I asked for transfer to OOo team on my own volition. Nobody made me do it,
neither in "We urgently need OOo hackers, so take it or leave Novell" sense,
nor in "Your work on YaST sucks, be so kind and leave" one. If OOo team hadn't
hired me, they'd have certainly found another smart hacker sooner or later.
The real reason is implied here:
>But actually the mailing list shows a lot of activity in webyast. I think
>most oldyast developers are working in that project, so it makes less
>and less sense to invest in a player when you intend to introduce a
>competitor a couple of releases later.
It didn't happen overnight, but yes - gradually all YaST hackers were
transfered to WebYaST and related projects, switching YaST into maintenance
mode with just enough room for urgent fixes and not much else. No features or
so.
I don't know whether anybody ever realized that WebYaST is not a replacement
of YaST (at least, not in the near future). Neither do I know whether somebody
thought that all users will now happily switch to WebYaST and stop using and
reporting bugs against "old" YaST (then all YaST hackers could be safely
transfered to the new projects without replacement). What I do know is that
none of the above was ever communicated to the users and the community.
So what happened to me is that when I was told to stop doing something I loved
(hacking YaST, talking to the users, implementing UI stuff) and start doing
something I ... let's say ... "like much less" ;) (hacking RoR, jquery & CSS
stuff) I chose to join another team instead.
I believe in better F/LOSS desktop future and I can contribute to that in OOo
team.
B. (who should've blogged about this some time in the past but was too blue to
do so)
--
\\\\\ Katarina Machalkova
\\\\\\\__o OOo developer
__\\\\\\\'/_ & hedgehog painter
Alberto Passalacqua
why this discussion goes on here and not on an official mailing list part of
the openSUSE infrastructure?
How are users and community members supposed to know what's going on if these
topics are discussed out of it?
> It didn't happen overnight, but yes - gradually all YaST hackers were
> transfered to WebYaST and related projects, switching YaST into maintenance
> mode with just enough room for urgent fixes and not much else. No features
> or so.
This is very interesting to know, since YaST is one of the few remaining
advantages in SUSE/openSUSE.
Switching it to maintainance mode has meant "nothing will be done on it" for
many other projects managed by Novell, which has been well known to let
projects die with the excuse of opening them and releasing them to the
community (Hula, iFolder, AppArmor...), and then trying to resurrect them when
some business opportunity appear, to abandon them again since the work to be
done to bring them back to life is too much.
Hopefully this won't happen to YaST, but it is hard to believe, and the fact
it was not said says something too on the consideration for the community
among those who take decisions.
Best,
Alberto
Ricardo Cruz
> why this discussion goes on here and not on an official mailing list part of
> the openSUSE infrastructure?
Well, I was just (trying) being funny in my reply to Atri.
Katarina amiably filled us in on her current job situation. That
wasn't something I was bargaining for. My best wishes. I'm
sure working with the inane yast, ycp and ncurses code was good
training for what she will find over openoffice.
Maybe she is happy to indulge us more on this topic, but I think
you're going to hear what is public knowledge already.
Anyway, I wouldn't take at face value what people tell you about
what the grand plan is when it encompasses so many people. Even if
they are in a position of direct decision making, they are speculating.
Think of how interlinked are the factors such decisions depend on:
technological
hurdles, developers abilities, users desires, managers egos... It's a
constant struggle for an executive to predict, much less know the information
necessary to make perfect targets. Albania would be paradise if you
could do that. You'll necessarily miss, and that's why you need projects like
webyast going on. First, they have to evaluate how development is going on.
Then run it through a test market to get an idea how embraced the
project is at that primitive state. ...
Cheers,
Ricardo
Atri
I understood from discussions at irc that might help users are:-
1. A menu item that says "Refresh all enabled repos" and does just
that. Helps if you have let your package manager open for a really
long time, and want to do a new install. Or you have completed a bunch
of package installations that has taken you about an hour or two, and
you want to install a new package without closing and restarting your
package-manager.
2.Refreshing auto-refresh enabled repos in the background. Not sure
how this can work, but something like this happens in packagekit
application manager now. Might be interesting to investigate further.
Big positivie out of this would be a great enhancement in start-up
times of yast2-gtk. Perhaps all change action buttons like install,
upgrade etc can be disabled until the background refreshing has
completed...
3. For the user who does not believe in cleaning out unneeded packages
at every uninstall time, a button/menu item somewhere that goes
"search for and weed out all unneeded installed packages". A user
might want to preserve some unneeded packages, for example to help him
with building stuff, and use such a button every once in 2--3 months
to do a weeding :)
Hope you find these points useful,
Bye
--
Atri
Ricardo Cruz
> Back to the topic at hand, what plans do we have for 11.4? Some points
> I understood from discussions at irc that might help users are:-
>
> 1. A menu item that says "Refresh all enabled repos" and does just
> that. Helps if you have let your package manager open for a really
> long time, and want to do a new install. Or you have completed a bunch
> of package installations that has taken you about an hour or two, and
> you want to install a new package without closing and restarting your
> package-manager.
The scope of that feature is wider than our UI code, so fill
up a bug report that I will CC the yast2 developer(s) responsible
for that stuff, to hear what they have to say.
> 2.Refreshing auto-refresh enabled repos in the background. Not sure
> how this can work, but something like this happens in packagekit
> application manager now. Might be interesting to investigate further.
> Big positivie out of this would be a great enhancement in start-up
> times of yast2-gtk. Perhaps all change action buttons like install,
> upgrade etc can be disabled until the background refreshing has
> completed...
Like the previous one, we should hear what the yast2 guys have
to say even if we then come up with patches ourselves.
But, unlike the previous one, this one will be pretty challenging.
> 3. For the user who does not believe in cleaning out unneeded packages
> at every uninstall time, a button/menu item somewhere that goes
> "search for and weed out all unneeded installed packages". A user
> might want to preserve some unneeded packages, for example to help him
> with building stuff, and use such a button every once in 2--3 months
> to do a weeding :)
Yeah, under the categories box, we have entries like "Suggested" and
"Orphans", and we should definitively add some for those kind of
loose packages.
The problem back then was that libzypp didn't give us a transparent look
at what those might be. But now it does support options like the "Cleanup when
deleting packages" one, so I will have a look at that...
C
>> 3. For the user who does not believe in cleaning out unneeded packages
>> at every uninstall time, a button/menu item somewhere that goes
>> "search for and weed out all unneeded installed packages". A user
>> might want to preserve some unneeded packages, for example to help him
>> with building stuff, and use such a button every once in 2--3 months
>> to do a weeding :)
>
> Yeah, under the categories box, we have entries like "Suggested" and
> "Orphans", and we should definitively add some for those kind of
> loose packages.
> The problem back then was that libzypp didn't give us a transparent look
> at what those might be. But now it does support options like the "Cleanup
> when
> deleting packages" one, so I will have a look at that...
Ummmm is this somethign that can be more general? QT and GTK?
C.
Ricardo Cruz
Short version: yeah. All Atri suggestions, once implemented, can
be trivially shared across UIs.
Long version:
Unlike the other yast2 tools, currently if we want to expand on
the software manager feature set, because zypp now supports
this new feature, we have to add a menu entry or list item manually
to each UI (gtk, qt, ncurses). But it's generally trivial to do that
(it certainly is in this case), at least for gtk and qt (ncurses API can
be a pain I'm told).
In this case, the hard working part is going through the zypp code to
find the way to come up with the query mechanism. I'm not sure how
zypp is logically structured -- I guess it works evolutionary by
mutation and natural selection -- because there are generally several
different ways to go about doing something. And the fact that it
exposes a lot of API that ought be private, only makes going
through the header files more time consuming.
By the way, if you guys hang out on IRC, you could go to the zypp
channel (#zypp I guess), and ask them about this feature: ask
them if there is an API to list "unneeded dependencies" -- and, if so,
what is the class or file name.
Ricardo Cruz
With regard to Atri's refresh related features, I wonder how other
distributions work in this respect. It really is a pain that the software
managers takes so much time to start, and it is worse the worse
your internet connection.
(btw, sometimes I just want to check some installed package, and
my network is cut from the Internet, so I have to wait quite a while
for the timeout. Pressing "skip auto-refresh" doesn't do anything for
me.)
I don't see Ubuntu or Mandriva taking any time refreshing when
I open their software managers, or use their command line tools. I
doubt they are doing the refreshing in the background, because I
don't see any UI indication. Your current package listing would need
to be updated after a refresh, so you should see some flickering effect.
I bet they just need refreshing from time to time, and they probably
do it when starting the system, or as a general background system
management thing.
It would be interesting to know for sure, just for curiosity's sake.
Anyhow, why is it important for the typical desktop user that the
repositories cache is synced to the second? How long do repositories
keep their packages after a new one is uploaded?
Instead of background threads, I'd prefer to have longer cache
lifetimes. Longer? What am I saying? It will check for updates after
I use zypper one minute later.
(If some information here is outdated, let me know. I am only using
opensuse from time to time atm.)
Sure, a new package version may be out, and it's (presumably) always
preferable to use it. But that should be the task for an automatic update
system. A desktop user should care only to pick application, and then the
system should be responsible for integrating new fixes and features, like
the user expects nowadays with web applications. (and, of course, it
should be easy to regress, or manually override any automation.)
And, by the way, why does the refresh sequence take so much time
anyhow? It seems to me like most of the time is spent "handshaking"
the several servers, rather than actually getting any data -- after all,
rarely does the cache needs to be updated. So, why doesn't it
connect to several servers in parallel? Sure, there is a local
bottleneck due to bandwidth constrains, so you may only want to open
up to N connections at a time (like RSS readers work), but, nevertheless, it
would be helpful to have a little concurrency.
Cheers,
Ricardo
Quoting Atri <badsh...@gmail.com>:
> 1. A menu item that says "Refresh all enabled repos" and does just
> that. Helps if you have let your package manager open for a really
> long time, and want to do a new install. Or you have completed a bunch
> of package installations that has taken you about an hour or two, and
> you want to install a new package without closing and restarting your
> package-manager.
>
> 2.Refreshing auto-refresh enabled repos in the background. Not sure
> how this can work, but something like this happens in packagekit
> application manager now. Might be interesting to investigate further.
> Big positivie out of this would be a great enhancement in start-up
> times of yast2-gtk. Perhaps all change action buttons like install,
> upgrade etc can be disabled until the background refreshing has
> completed...
Ricardo Cruz
While I am at it, another problem with the refresh sequence is
that any errors are reported immediately. If a server is down or
whatever, it should resume the refreshing, and then nicely tell
me about any errors at the end, before it lets me use the software
manager UI.
Anyhow, a couple of years ago, I was told the plan was to migrate to
PackageKit. Meanwhile, the zypp backend is very usable, it just requires
some more manpower to provide some more functionality. When
some big distribution adopts it and create a momentum, it will probably
become the go-to software manager for opensuse too. And there's
the promising webyast too, which will not be compatible with current
yast code.
So, we have to balance the effort needed to address those issues
with the fact that the fix may not survive for long.
Cheers,
Ricardo
Ricardo Cruz
Have you filled up bug reports for these babies yet?
Quoting Atri <badsh...@gmail.com>:
> 1. A menu item that says "Refresh all enabled repos" and does just
> that. Helps if you have let your package manager open for a really
> long time, and want to do a new install. Or you have completed a bunch
> of package installations that has taken you about an hour or two, and
> you want to install a new package without closing and restarting your
> package-manager.
So, this would be helpful for when the software manager restarts
("close software manager window when done" disabled) after a
long time of downloading and installing stuff...
Are there other use cases you can think of? Given that the
software manager already auto-refreshes on start, this seems
to be the only event when an auto-refresh is needed.
I would therefor address this issue by having the software
manager auto-refresh on restart. We can use a timestamp
to make sure this only applies if, say, 30 minutes have lapsed.
It avoids unnecessary UI and code complexity, and it seems
something that the feature audience would prefer. You don't
have to remember to auto-refresh. Those of us with mild
obsessive-compulsive behavior would also prefer not having
the choice to make sure repositories are refreshed to the
second. ;)
Atri Bhattacharya
Hi Atri,
Have you filled up bug reports for these babies yet?
Sorry, not yet. I was away for a few days. I am going to fill up the bugs right now.
So, this would be helpful for when the software manager restarts1. A menu item that says "Refresh all enabled repos" and does just
that. Helps if you have let your package manager open for a really
long time, and want to do a new install. Or you have completed a bunch
of package installations that has taken you about an hour or two, and
you want to install a new package without closing and restarting your
package-manager.
("close software manager window when done" disabled) after a
long time of downloading and installing stuff...
Are there other use cases you can think of? Given that the
software manager already auto-refreshes on start, this seems
to be the only event when an auto-refresh is needed.
The other user case is marginal: someone disables all repositories for whatever reasons, and then uses the proposed button to refresh all enabled repositories [but not auto-refreshed] all at once.
I would therefor address this issue by having the software
manager auto-refresh on restart. We can use a timestamp
to make sure this only applies if, say, 30 minutes have lapsed.
It avoids unnecessary UI and code complexity, and it seems
something that the feature audience would prefer. You don't
have to remember to auto-refresh. Those of us with mild
obsessive-compulsive behavior would also prefer not having
the choice to make sure repositories are refreshed to the
second. ;)
That would not help the second use-case I was thinking of above. It would be useful, though, for the majority of users anyhow (i.e., whether or not we implement such a button). For what it is worth, such a button "Refresh all enabled" already exists in the repository manager, though not in the main package view. I understand it does refresh not only the Autorefreshed repositories but also those for which Autorefresh is disabled.
--
Atri
Atri
1. https://features.opensuse.org/303517
2. https://bugzilla.novell.com/show_bug.cgi?id=346966
I guess those two, coupled with relevant portions of what is mentioned
at
http://news.opensuse.org/2010/09/02/opensuse-announce-first-11-4-development-milestone-with-improved-package-management-performance-new-xorg-kde-and-gnome/
serve a better purpose than what I had suggested here.
--
Atri
Atri
On Sep 1, 5:49 pm, "Ricardo Cruz" <rpmc...@alunos.dcc.fc.up.pt> wrote:
>
> > 3. For the user who does not believe in cleaning out unneeded packages
> > at every uninstall time, a button/menu item somewhere that goes
> > "search for and weed out all unneeded installed packages". A user
> > might want to preserve some unneeded packages, for example to help him
> > with building stuff, and use such a button every once in 2--3 months
> > to do a weeding :)
>
> Yeah, under the categories box, we have entries like "Suggested" and
> "Orphans", and we should definitively add some for those kind of
> loose packages.
> The problem back then was that libzypp didn't give us a transparent look
> at what those might be. But now it does support options like the "Cleanup when
> deleting packages" one, so I will have a look at that...
--
Atri
Ricardo Cruz
Hi,
This is the just like the behavior we were discussing about. It would
be pretty cool indeed.
Something that seems absent from the discussion in the bug
report is that repositories only hold outdated packages for awhile.
(right? and I guess some repos keep pkgs for longer than others too)
If that's true, options like "monthly" refresh are just allowing users
to shoot themselves in the foot. When they use the software manager,
unaware that some of the packages listed are only shadows of past
versions, they may inadvertently break their RPM database.
Remember that libzypp downloads one package at a time, so it
may very well upgrade a few dependencies, only to find itself
unable to proceed after some point, because the package is no
longer there, and the system falls into disrepair.
Hopefully, following this feature, the repositories will converge to
similar package lifetimes, so the user can be confident that the
refresh time he uses may not be optimal, in the sense new versions
may be there already, but at least it won't be tragic either.
I also wonder why is it useful to let the user choose what weekdays
he wants the cache to be refreshed. Why not just have options
like "Every 2 days" or whatever. Any advanced user that needs to
specify "not on fridays, between 5 and 7 pm" or whatever, can then
just tweak the respective cron job.
On the other hand, I guess no desktop user will want to change
the defaults, so we don't lose anything by making the thing insanely
configurable.
I just wanted to run my thoughts through here first, since I may
be missing something...
Ricardo Cruz
>> Are there other use cases you can think of? Given that the
>> software manager already auto-refreshes on start, this seems
>> to be the only event when an auto-refresh is needed.
>>
>>
> The other user case is marginal: someone disables all repositories for
> whatever reasons, and then uses the proposed button to refresh all enabled
> repositories [but not auto-refreshed] all at once.
Oh, right. You can enable repositories, but disable them refreshing
automatically.
Pretty dangerous option incidentally. Given that zypp only checks and
downloads packages as it installs them, it's important the cache reflects
what's in the repository.
So, I would vote to only show such an option when it's applicable (for
people that have auto-refresh disabled for some enabled repository). And
fix the other use case the way I mentioned.
Anyway, people only play with such dangerous options because it
takes so much time to start the software manager. I think the bug
report you mentioned (about cron job to refresh repositories)
would obsolete such options.
But we could still address this feature, in case the other one doesn't
get any love. I would thumb it down though, because it doesn't seem
to worth the couple of clicks it saves, but I would surely implement it
if others like the idea.
Ricardo Cruz
> By the way, if you guys hang out on IRC, you could go to the zypp
> channel (#zypp I guess), and ask them about this feature: ask
> them if there is an API to list "unneeded dependencies" -- and, if so,
> what is the class or file name.
http://lists.opensuse.org/zypp-devel/2010-09/msg00000.html
They haven't responded. I don't think there is a fast or
reliable way to do this.
In follow up mail, I come up with a possible hack, but it's
not 100% reliable. Any error would be of type II though (false
negative), so it might be worth a shot -- since, at worst, the
list won't be complete enough, but you will never wreck your
system.
There is this nice tutorial for using libzypp from python, so
I will give this one a try:
http://lizards.opensuse.org/2008/10/03/developing-with-libyuilibzypp-python-part3/
Cheers,
Ricardo
Ricardo Cruz
> In follow up mail, I come up with a possible hack, but it's
> not 100% reliable. Any error would be of type II though (false
> negative), so it might be worth a shot -- since, at worst, the
> list won't be complete enough, but you will never wreck your
> system.
Actually, no. There's the potential for showing false unneeded
packages too...
I didn't remember that /var/log/zypp/history makes no distinction
between packages that were installed via the dependency solver, or
via a patch.
Also, I don't think zypp provides a reliable way to tell dependencies
(it only tells you raw strings like "Recommends: gtk2-2.8", which
we may parse incorrectly -- I don't think the dep solver exposes its
parsing functions.)
I already spend a little time on this, but I got quickly frustrated with
libzypp. The damn API seems completely illogical.
Anyway, if you do a fresh install of 11.3, you can enable the
option "Options > Cleanup when deleting packages", and that will
make sure any unneeded dependencies are removed.
(Both the qt and gtk plugin show those menu options. And there
should be available some zypp config file to change that option
globally, so it also affects zypper and the ncurses plugin.)