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

On Sun, Jan 11 at 22:46, Dominique Devriese wrote:
> 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/.

I'd have to check it. I have never found time to dig deep enough into
libapt structure but I always thought the descriptions are present in
the apt binary cache exactly like other data is. It's just more logical
for me. The PackageFile here, as always, represents not a real file on
the disk but only the abstraction of a file which was used to create the
cache. At least after /var/lib/apt/lists/ files removal you can still do
"apt-cache show pkg 2>/dev/null" and see the descriptions. And when you
create pkgRecords you give the constructor the pointer to cache so it
should use it :)

> This is also the reason why apt-cache search is pretty useless ( uses
> only the names of the packages, and their Provides lines )

Well, it doesn't. You can try e.x apt-cache search 'next generation
front-end' to see that it looks also at the descriptions. The apt-cache
source was even the place where I have learned how to access them.

[...]
> 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 ) 

User thinks it's not a package average user should think about, and
rightly so :) I just don't have an impression the package names for
packages interesting for the user are bad - they are usually just the
program names. Maybe sometimes they can be changed but I cannot find
many examples where the name with the short description would not be
enough. Tried "kmail - KDE Email client", "kstars - desktop planetarium
for KDE", etc. Almost every time something I couldn't name better. Maybe
they are too long - if we have only one desktop planetarium there is no
need to write it's "for KDE" but I don't think it's a big problem.

[...]
> 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 ), 

Hmm, Anaconda? It's already ported to Debian :)

> 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 )

This list shouldn't be taken as the reference since it reflects only a
particular Live CD development snapshot. There are many packages that we
will remove and many absent we will add. But I agree the Live CD can be
taken as the first selection draft.

> minus the number of "under-the-hood" packages that are in there.

Right. Those packages will probably be the vast majority of all the
packages present.

[...]
> Sorry about the long mail, but what do you think of the idea ?

If you are thinking about creating additional structure like the ones
used for example by KDE menus it is an interesting possibility. I'm
not UI expert but this form of presentation is commonly employed as more
intuitive for a user. Maybe this could be coded in the way where by
default the name/short_description pair is displayed but this text can
be overwritten when we decide we want something else? The text would be
much longer than usual menu entries but I think it has to be when user
has no possibility to start the application to see what it does. This
package management menus will not be used every day so entry access can
be somehow slower. If you also want to group the packages, it can be
easily achieved by dependency pseudo-packages like for example koffice.
The problem with it is that when you uninstall the package its
dependences are not uninstalled so maybe this is something the package
manager also should take care of. 

Regards,

-- 
Marcin Pawlik