Linux and application installing - a second perspective

[FlorianFesti]

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/