Mailinglist Archive: opensuse-factory (599 mails)

< Previous Next >
Re: [opensuse-factory] Announcing Yast-GTK
  • From: Andreas Hanke <andreas.hanke@xxxxxxxxxxxxxx>
  • Date: Wed, 23 Aug 2006 21:06:11 +0200
  • Message-id: <44ECA723.6040905@xxxxxxxxxxxxxx>

Ricardo Cruz schrieb:
> Yes, that's always nice to get. :)

OK ;-)

> Now in SVN only available patches are displayed.

What does "available" in this context mean?

I know, I can make a new checkout myself ;-)

> Do you, as a
> user, have the need for an installed patches catalog?

I don't know if there's a "need" for that, but I'd like to have it -
clearly distinguishable from the patches which are still needed.

What I would to have like is:

- A default view that presents only those patches which make sense for
my system. That is, those patches that are either not yet installed, or
installed, but broken (e.g. by manually downgrading a package to a lower
version than the patch defines).

- The default view should display only those patches described above and
neither installed and fulfilled patches nor patches that don't apply to
my system (e.g. because none of the base packages that makes up the
patch is installed).

- Optionally, an extended view that shows which patches I already have.
This functionality is not "needed", but a user might want to review
these (e.g. a patch broke something - this happens from time to time -
and the user wants to know which patch is to blame). This should be
available if possible, but not in the default view.

- Difficult question: How to handle patches that are fulfilled, but not
installed. This happens when the user directly installs an updated
version of a package instead of installing the original version and then
patching it. This is a difference technically, but the interesting
question for the user is whether he needs that patch. And since the
packages are up-to-date, IMHO this case should be handled as if the
patch were installed although it is actually not.

Fancy Idea: There could be two "pools" of patches, similar to the two
"pools" in the software installer. One of them holds what I already have
and the other one holds what I can get. The destinction between these
must be clear and intuitive, much more than in the qt frontend.

> And btw, can you remove installed patches?

That's a difficult one ;-)

Neither qt YOU nor ncurses YOU provide an interface for removing
installed patches, but rug and zen-remover do (not working). But this
feature does not make too much sense as long as tabooing patches is not
possible (with "tabooing" I mean "never ever install this patch and
don't even ask" - none of the update tools supports that currently).

> Sort by status? Did you mean "sort by severity"?

No. With "status" I do not mean the severity.

With "status" I mean one of:

(1) Not applicable (cannot be installed on this system)
(2) Not needed (not installed, but fulfilled by the installed packages)
(3) Already installed and fulfilled
(4) Already installed and broken (reinstall needed)
(5) Neither installed nor fulfilled (installation needed)

The default view should include (4) and (5); an extended view should
include (2) and (3); (1) does not need to be accessible from the GUI in
my opinion.

The severity is also important, but that is just for sorting the patches
and deciding whether they are pre-selected by default. The "status"
decides whether a patch is displayed _at_all_.

When implementing the "pool" idea - I don't know if it's a good idea,
it's just a proposal - the "is installed" pool should contain (2) and
(3), the "can be installed" pool should contain (3) and (4), and (1) can
be left out. The user doesn't need to see them.

> I understand the feeling that a user may get information on a website that
> doesn't apply to his Yast frontend, but only the package selector interface
> is different and if we make it easy to use, such websites won't be necessary.

That's a good point. The ncurses and qt frontends were already different
until SUSE 10.0 and there was never a need to explain anything. The
confusion started with SUSE 10.1.

So you are probably right, assuming that each frontend is easy to use on
its own, they are allowed to be different.

> Maybe we shouldn't offer the YOU interface and direct the user to
> zen-updater? I dunno, but I guess the best is to provide it and the
> distribution should be the disabling it, if it wants to.

Yeah, that's this well-known and problematic duplication of tools... But
YOU and Zen-Updater still don't obsolete each other. For example,
Zen-Updater requires root to grant _permanent_ zmd privileges when used
from within a user account - without doing that, Zen-Updater refuses to
do anything, while YOU accepts the root password for single sessions
just fine.

This is something that many users don't like about Zen-Updater because
it breaks the traditional root <-> user separation. It's one of the
reasons why YOU is still popular. The Zen-Tools are integrated with the
desktop, YOU is integrated with the rest of YaST, and they are very
different. So we still need YOU.

> But aren't the problems more related with the so many choices? You have Yast,
> Zen, Synapitec together with the command tools, and different repository
> systems.

Yes, that is another problem, but a separate one. Maybe we - the users -
should reconsider recommending alternative tools too intrusively.
Urging users to use other tools doesn't help avoiding confusion,
especially since sometimes they don't play well together. It's a complex
thing that doesn't have anything to do with YaST-GTK ;-)

Apart from that, YOU alone _is_ currently confusing - let's hope that
the new gtk YOU becomes really cool and causes the other YOUs to become
cool again as well ;-)

> I dunno, but I'd really like to avoid Yast-Qt's package selector...
> It's unnecesarly complex and I understand why it badly needs documentation.

I'm not sure whether I get the terminology correctly here. Is it correct
that the package selector is what I see when launching sw_single.ycp?

If so, it's OK for me. Most of my complaints are directed against what I
see when launching online_update.ycp.

> Anyway, we haven't yet discussed the Yast-GTK package selector interface with
> the Yast team. I will start a discussion about that next week. yast-public
> would be the appropriate place, so if you want to register (its very low
> traffic):

Great, of course I'd like to follow the discussion if it's public.


Andreas Hanke
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >