Re: Re: RFC: Keywords - Aptitude has similar solution included

[Daniel_Burrows@brown.edu]

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

  As I said, this is an experimental mode of operation --
by default, you press "left" to go back (think about lynx)

  I'm not sure what the best keypress to use is.  I tried "q" at one point, but went back on that.

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

  ok.  I may have skimmed too quickly (curse webmail)

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

  I may have been about to say something like
"you can distribute alternative categorizations which
work better for you".  ie, you aren't confined to
whatever the package maintainers come up with.

> > (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 problem with this is that the most important feature
of classification is consistency.  I had to make a lot of
judgement calls in gray areas, and I'm sure even I wasn't
totally consistent.

I'm willing to give this a shot, anyway.  It's obviously
fairly easy once we have data to get it imported somehow.

And, of course, there's no reason we can't have both a
centrally maintained list of categorizations and a
distributed one.

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

IIRC, the STL string class has a copy-on-write behavior.
That may not be what you were referring to, 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.

  ah, yeah.  I was considering trying to do this, but
I felt it was too hard to get the different levels right.

  You could probably extend the code to do this fairly
easily, but I'm not sure how well it'll work in practice.
  (sorry to be skeptical, I just want to make sure what
we end up is as good as possible)

  Daniel