Abstraction over Debian Packages in Kapture (was: [devel] Another idea)

Marcin Pawlik writes:

>> I played around a bit with making Kapture not show the Debian
>> package names in the list view, but instead the short description.
>> I have got some code running, but it is unfortunately
>>
>> 1. Pretty slow ( the short and long descriptions are not part of
>>    the cache that apt maintains,

> AFAIK they are. Don't know if this is the fastest method but you can
> create pkgRecords object and call its ShortDesc() and
> LongDesc(). The only thing I remember useful for average user and
> not present in apt cache is the list of package files.

>> so they have to be gotten from the packages files directly ).

> Are you reading the data from /var/lib/dpkg/info? 

No, you misunderstood me.  I was talking about pkgRecords.  IIUC, it
gets its information not from the cache, but from the package files in
/var/lib/apt/lists/.  This is also the reason why apt-cache search is
pretty useless ( uses only the names of the packages, and their
Provides lines ), and "grep-alternatives" is far better in many cases.

>> Thus, the displaying of the entire list takes quite a while ( as in
>> half a minute or so )

> What is the entire list? List of packages installed or available? 
> How many packages are in there and why do you want to display
> descriptions for all of them, not only for the ones at the moment
> visible for the user?

You're right about this.  I have thought about this too, but haven't
had the time to do it yet.  Help is always welcome, of course ;) 

>> 2. Pretty unusable.  The current Debian package Descriptions are
>>    not
>> usable for this purpose.  They're meant to be shown alongside the
>> package name, not instead of it.  I would personally like it
>> otherwise, as the package names are obviously not interesting to
>> the user

> For me it is. For example when I look for some program I start from
> searching for the package having this program name as a part of the
> name. The description along with the package name is of course
> really handy but the name IMO should also be there.

Well, currently, I agree with you, because the current "short
description"s are for a large part such that they rely on the name
being shown too in order to be informative ( even though the Debian
policy specifically says this is wrong ). 

However, don't you think that it would be better if we could ditch the
package name ( imagine what a user thinks when he sees a name like
libqt3c102-mt ) in the public interface, and replace it with a single
proper, user-friendly, translated description ?  There could of course
still be an interface to search for a package by name ( so you can
tell a user to install the package libqt3c102-mt to fix his probs
e.g. ), but the major inteface should not show it.

I have been thinking further about it, and imho, we will never be able
to provide a nice Package Installer Interface that is anywhere near
the Red Hat one ( that someone posted a screenshot to ), unless we
provide an extra level of abstraction over the Debian packages.  A
very rough mind sketch of this idea would be to add a separate data
file containing metadata about some limited set of packages that we
think the user may want to install.  We could keep data in there like
icons, proper, user-aimed descriptions ( the current ones are all
aimed towards a technically capable admin, as Debian policy requires )
and a grouping system.  The number of packages could be kept as low as
one hundred, I think, not any more than the number of packages
included on the live cd ( check out
kdenonbeta/kdedebian/livecd/packagelist/alpha6_list ) minus the number
of "under-the-hood" packages that are in there.

I would propose to make such a list, consisting of packages that
fulfill the following criteria:

1. The user knows they exist ( exclude library packages, kernel
   packages, base and essential packages, perhaps even all non-GUI
   packages ).
2. They have a certain amount of popularity, or are likely to gain
   it.  This is of course a very arbitrary decision, but I'm sure it
   is possible to make it.

We could then make a very user-friendly package manager, still
enjoying the power of apt under the hood.  If you feel inclined to
reply "but what if I want to install rarely-used terminal application
XXX", think about the following point:

We're not working on a package manager for ourselves, but for users.
There's nothing to stop us from doing apt-get install xxx, it can even
be used alongside the pkg-manager I'm proposing.

Sorry about the long mail, but what do you think of the idea ?

cheers
domi