Categorization of packages (was Re: Aptitude, ARs)
hi,
On Wed, Mar 12, 2003 at 05:16:17PM -0800, Osamu Aoki wrote:
> APTITUDE is great :-)
Yep. Its bug list too, unfortunately :-/
> Currently, about 2/3 of packages are properly assigned in "new
> Categorical Browser".
OK, I tried it out today. AFAICT, the new categorical browser (NCB) is a
different view of the packages. I.e., you lose all the nice 'New
Packages', 'Installed Packages' etc. and instead have a flat categorical
view. And I've found no way to go back to the main categorical view,
hitting 'q' results in exiting the NCB.
It would be much more sensible to just replace the Sections in the
normal view by categories (making it a 'UI options'). Or did I miss
anything? Is there a chance this will be changed before sarge? Otherwise
its usefulness is limited I'm afraid.
> Daniel pretty much sorted out manually. But this means 1/3 and
> growing numbers of packages are UNCATEGORIZED. This is due to the
> fact categorization was done with static data within aptitude and
> Debian has no automatic mechanism in place to update them.
> I want to make some update on this data but I am not sure when I can
> finish it. It is time consuming...
Well, this needs manpower. Fortunately, it does not need l33t C++
hacking skills, so we could probably get some volunteers quickly if we
motivate them.
BUT: We should NOW decide on a new Category-Policy. At least the
following points should be discussed before we even waste our time with
implementing them in aptitude, let alone trying to do them for dselect
or policy:
(For everybody interested in the NCB structure, but unwilling to
install/firing up aptitude now, check this out for the same data:
http://people.debian.org/~erich/packagebrowser )
1. Seems like Daniel more or less retained the old Sections as first
level categories. Do we want to go a step further?
I feel that it might be easy to just modify the Section:-field policy so
it says that there can be one or more Sections (like Depends:), with a
syntax like: "Section: mail/client, desktop/gnome". That way, the other
frontends might be quite easy to change to at least not choke on the new
layout, as long as the first word is out of one of the old sections.
OTOH, now is the time and chance to really think up a new layout, so why
don't we do it right?
2. How many Sublevels do we allow? Only one or more?
Daniel does more than one and I think this makes sense.
3. Can a package be in more than one Category?
Currently, about 10% of the packages categorized seem to be in more than
one section. I still think it might be worth having e.g. GNOME packages
be categorized both as desktop/gnome and foo/bar.
> We need to polish this proof-of-concept aptitude feature "Categorical
> Browser" before the release of Sarge. Then, we can propose new policy
> which require new debian/control entries or other machanisms to do it.
agreed.
> I also see great possibility for aptitude's 'l' command which enables us
> to limit scope of package displayed based on some rules.
Ehm, when I hit 'l' I get:
|Enter the new package tree limit:
|!~v
Without a 'Help' Button. Doesn't look very intuitive for me.
> Package: gnumeric
> Attribute: C, ISO-8859-1, UTF-8, desktop=100, GNOME, server=50, develop=0, en, fr
>
> Package: mc
> Attribute: C, ISO-8859-1, desktop=100, console, server=50, develop=0,
> en, fr, pt-br
> ---------------
>
> My idea goes: If 'l' option is set to (desktop > 100), it selects all
> desktop packages, while (desktop >1000) only select the core of them.
>
> Currently "task" infrastructure only offers on/off control of package
> recommendation for a task. This new method may enable finer grained
> presentation.
And it will take much more effort to get the data right than just
categories.
Michael
Reply to: