Re: RFC: Keywords - Aptitude has similar solution included
> Several months ago, I added support for better
> package classification to aptitude. To try it out,
> select "Browse Packages By Category" from the Views menu.
> (this uses a different, experimental display mode -- use the "hier"
> grouping policy to see it in the normal expandable tree style)
Very Useful for beginner's i think. Although i had problems with the
keyboard mapping, how do i go back?
> The idea is quite similar to your suggestion, except that:
>
> (a) It is hierarchical, so the number of items on the screen
> at any one time is manageable.
My system definitiely is hierarchical, but NOT with fixed hierarchies
(although keywords might be ordered hierarchical themselves)
> (b) It uses external datafiles, so we don't have to change
> the archive, and you can (theoretically) use
Which i would use as a transitional solution.
Unfortunately, the later part of your sentence was lost.
> (c) It is implemented in a package manager available in the
> Debian archive.
That's definately a BIG plus ;)
> (e) Mostly-complete data sets exist for it.
> Don't underestimate the difficulty of categorizing
> 6000+ (and counting) packages! My sample categorization
> leaves out a lot of packages, and is not particularly
> deeply thought-about, and it still took me literally
> weeks, working a few hours a day on it, to get the
> data made. (part of this was that I spent some time
> working on getting the tools right, but..)
That is why i don't want to categorize them myself. This should really
be done by the package maintainers themselves, they know their software
best. Until they updated their package, the package manager can of
course use an override file (which could then be used for building the
mirrors and get the data into the mirrors that way, as with Task: ;).
> The one major problem (aside from the fact that it's not
> as general as some people [0] would like) is that the
> current implementation is VERY slow. Patches to fix this are
> welcome...uh...as soon as I get a new power supply, anyway.
Yeah, speed was one of the big problems with my experimental implementations
in perl as well. With an optimized pointer-instead-of-copying
implementation in C this should get way faster though.
Your solution and my concept are more different than you think.
You basically put the packages into a given hierarchy, whereas the
hierarchy in my concept is to be generated on demand by the user.
If he prefers, he can go x11 -> gnome -> mail -> mta, but he can also go
mta -> not-kde -> gnome, if he prefers.
But it's merely a concept with no real implementation yet.
But the Keywords: field i'd like to have added and your "Parents:" Field
_work_perfectly_together_.
So if we'd put up a keywords list (and
/usr/share/aptitude/function_groups is a great starting point!),
developers could start adding this keyword field to their control files.
Then aptitude could use this additional information with almost no
changes to your source, and future developments can build upon this
base.
Unfortunately, i will not have time to implement my concept in C++ until
Christmas, due to me currently spending lot's of time at the university
(well, i'm doing about twice as many courses as most people i started
with... so i'm quite loaded with problem sheets and courses...)
I'd love to see some of this development in woody, but time's too short.
Maybe the dpkg and policy experts could answer this questions:
- Does dpkg need any modification to deal with the "Keywords: " field?
- Does the (already frozen?) policy allow this new field to be added
if it does not have any effekt on other packages? It then could be a
nice-to-have field for woody, so early updates and package managers
like aptitiude could already benefit from it?
Or maybe we should really keep this in unstable first. Although the
browser in aptitude looks _very_ promising.
Greetings,
Erich
Reply to: