[devel] Re: Abstraction over Debian Packages in Kapture

Marcin Pawlik writes:

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

Well, they aren't.

> It's just logical for me. 

To me as well, however, that's not how it works ;)

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

>From looking at some strace output, it appears that apt-cache uses
/var/lib/dpkg/status as a fall-back when /var/lib/apt/lists/* are not
available or don't list the wanted package.  Try using it on a file
that is not installed on your system when you have removed the
/var/lib/apt/lists/* files.

> And when you create pkgRecords you give the
> constructor the pointer to cache so it should use it :)

That would be too easy ;)

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

Yes, sorry, you're right about that, I was confused by the
--names-only code in apt-cache.cc

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

Hm, yes, I may have been a bit prejudiced from looking at the long
annoying list of package short descriptions in my test ( including the
"under-the-hood" packages, I mean ).  For most desktop packages I have
tried, the short descriptions are pretty good indeed.  In any case, it
would still be necessary to have a user-visible package name ( "KMail"
instead of "kmail", "KOffice" instead of "koffice" etc. ).

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

AFAIK, anaconda is an installer, and we're talking about a package
manager. 

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

Yes, of course, I was taking the livecd package list only to estimate
the number of packages that would be necessary in our list.

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

Absolutely.

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

This is my impression as well.

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

Yes, the problem is that for some packages ( like kmail, kstars etc ),
the standard description from the .deb's is just fine.  However, for
packages like mozilla, gimp etc, they contain information that would
not be relevant to our system, and has the potential to confuse the
user a lot.

> This package management menus will not be used every day so
> entry access can be somehow slower. 

Sorry, I don't understand this sentence.  Entry access ?

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

Yes, I am not sure whether it would be possible to provide and
continue to provide a perfect mapping from our concept of packages to
Debian's, so maybe we should drop the immediate correspondence, and
make our own packages tree, where each of "our" packages specifies
what debian packages it "depends on".

cheers
domi