Hi, 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): http://forge.novell.com/mailman/listinfo/yast-public
Great, of course I'd like to follow the discussion if it's public. Thanks! Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org