Sorry, for showing up late at the party. This mail should have been part of Richard's thread with the same topic but things took a while until they were ready enough to be presented here. There is a long history of package installers in Fedora (and it's predecessors). It feels like roughly every two or three years we switched to a new application for installing, updating and removing packages - most of them introduced as the default tool way before they reached the necessary maturity and being replaced before fulfilling the promises made on introduction. I find it pretty hard to see any progress in that area over the last decade - expect the current updater; it's actually the first one that really works. What has made the situation much worse is the insane (sorry) growth of Fedora during the last years. It puts every part of the distribution dealing with packages under stress. Design decisions that might have been reasonable (or at least not too relevant) turn out to be pretty stupid or at least insufficient. This is not only true for algorithms and data structures but also for user interfaces. Splitting the distribution up into a couple of groups and list the packages belonging to each group might have been a good idea while the distribution was still only 800 packages. Right now showing a list of packages won't work reasonably for the very most cases. Nevertheless this is the best we have to offer to the user right now... But just blaming PackageKit (or any of the other package installers) for not just being better is not really helping. They can only operate on the data available. So I tried getting an overview of what we already got and to find out how it could be used. As the number of packages and applications (about 20k and 2k) is too big for manual processing it was pretty clear I had to write a little application for viewing and browsing the meta data sets and the matching packages. It was also clear that such an application would be pretty close to a new package installer and I really didn't wanted to be the next one to replace the installer of the year by it's even worse successor - especially knowing that someone else will do that in a not too distant future anyway. So I wrote a little GUI program[1] with several things intentionally unimplemented. Most other stuff is just a mock up implementation short circuiting the normal data flows through Fedora infrastructure and the repositories. So it's just above 300 lines and tries hard to look harmless. Otoh it is also a mock up of a UI for browsing packages that - while not refined enough to be used in PK (or it's successor) as is - I consider a step to gain back control over the huge number of packages and applications. IMHO the goal is to allow the user filter down the list of packages of interest to one, at most three dozen packages. Typing in the right package name does not count as a solution! Back to the application itself: You can add tags/groups to the filter by double clicking on the entries in the treeview on the left or by entering a search term into the text field on top. To remove them from the filter just press the button representing it on the row above the result list. The numbers behind the tags are the number of packages in the current result and total. Starting the first time can take a while for downloading the repo data. The meta data it currently operates are: 1) Comps groups. Not even used by PK to the full extend. Nevertheless several groups are huge with over 100 packages (winner being "Games" with over 300). Sorry, 100 packages in one list view doesn't work for me. 2) PkgTags which are in the PackageDB but look like being in large parts autogenerated from the menu entry tags that are used to sort the applications into the menu entries. They look pretty outdated or incomplete, though. See [2] for a repo containing the data and the implementation in yum. You'll need the repo enabled to see those tags! PackageDB also allows to add tags by hand. Probably a good thing. Mixing them with auto generated ones - probably not. 3) Data found in the *.desktop files representing entries in the application menu. While I extracted them on my own the data set is basically the same as that used in PK. But here they are used to tag/group packages and not to make packages look more beautiful and less confusing - what seems to be the goal of the recent development in PK. There are two ways this data is used: 3.1) Attaching tags used to sort the applications into the menu to the packages. These allow different "views" on the packages, sorting them by different tags/aspects. Making a the tags available allows creating queries that are more narrow that the application menu itself. 3.2) Use the application menu (with additional *-menus packages) to sort the packages in. This is more easy to use but not as powerful as the tags. Every package/application is located where the user would expect it/is supposed to find it in the applications menu. The structure is though similar to the comps groups but some of the menus are more detailed as the comps groups are. Be aware the implementation is pretty simple. For an real UI one would filter out some of the tags. Also the menu structure still has duplicates that can easily be avoided. 4) Searches. While yum and all GUI applications allow searching the searches are isolate from all the other stuff. So as soon as you do a search all the groups and categories are of no value any more. To avoid that I tried making searches a first class citizen in my UI that can be used as filter just as everything else. That was you cannot only see in which groups the resulting packages come from but also filter the results down to groups or tags. It might make sense to have a couple of interesting searches that are precreated in the UI, but I have not yet made some up (may be "*.devel", or "*lib*" for the non application stuff). The UI does not support searches in different parts of the package yet (name, summary, description, files). Implementing that with a combobox similar to the Thunderbird or Firefox search boxes should be pretty easy. 5) Repositories. More or less a corner/power user case. But adding them was too easy... Other thoughts and ideas: The UI clearly is not intuitive yet although the concept is pretty simple. May be an UI person can give some hints for reimplementers. The status of the package could probably also just treated the same way offering a "updates", "installed", "available" tag. This would give a consistent UI for all ways to view packages. May be the UI should completely refuse to show long lists of package and give just a summery forcing the user to refine its search/view to a sensible result size. Not really fitting into this UI concept but still interesting: Generate a packages section as found in a kickstart file and show this as "Installed Packages". Remove all packages required by others and reduce packages to groups whenever possible. May be even to a group with some packages missing. Minimizing the number of lines should get pretty good results. Ok, I hope this is enough food of thought to keep the discussion about future UIs for handling packages going. I'd be interested about other ideas where to find package meta data or even more clever uses of the data we already have. I know there are a couple of people working on this topic from different ends. One main purpose of of the application is trying things out without bothering with a complicated (and complete) implementation. So patches and ideas are welcome. Have fun! Florian [1] http://fedorapeople.org/gitweb?p=ffesti/public_git/pkggui.git;a=summary [2] http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ http://skvidal.wordpress.com/2010/08/19/searching-package-tags-from-the-pkgdb/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
