8:51 a.m.
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-p...