[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Categorization of packages (was Re: Aptitude, ARs)



On Fri, Mar 14, 2003 at 10:29:50AM -0500, Daniel Burrows wrote:
> On Fri, Mar 14, 2003 at 05:36:53AM +0100, Michael Banck <mbanck@debian.org> was heard to say:
> > > 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. 

Daniel, I thought there is a way to limit display with 'l' command?
How can we use it to address above question?  (For long term solution,
we need menu driven interface or special effects on display.  Well, I
found the answer below.)

> > 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.
> 
>   The browse mode is a bit of an experiment -- my feeling was that it
> was somewhat easier to navigate (when you were working with categories)
> than the standard hierarchy.  You can adjust the grouping policy of the
> main view to include categories by typing "G" and replacing the two
> section(...) invocations with "hier".
> 
>   Oh -- I just figured out what you mean about hitting "q".  The browser
> was set up to use "left" to go "back" and "right" to go forwards.
> 
>   Anyway, the navigation style in the browser is somewhat buggy and
> experimental (as opposed to the underlying hierarchy code, which works
> fine AFAIK)
> 
> > 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.
> 
>   Yes.

Yep.  I am playing with it.

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

This, in short, is proposing tagged collection.  I see it as a keyword
approach.  If you look Daniel's menu in details, it does try to do
realize this.  We can change tree generation algorithm inside aptitude
to accommodate some keyword based trees with limited 1st level branches.

At the same time, current "Categorical Browser" can be fed with a data
generated with keyword approach.  This latter was the thing I was
considering since tagging package is time consuming and directly
creating Daniel's current feed data is a bit too tedious and error
prone.

> > 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?
> 
>   That might be a good idea; there's some cruft in the list of toplevel
> categories.

I have already fixed it locally.  Not that urgent.

> > 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.
> 
>   Obviously, I think this is a good idea :)

I agree.  
I think it will be more like:
 desktop/gnome/wordprocessor -> abiword
 desktop/wordprocessor/gnome -> abiword
 desktop/wordprocessor/tex   -> lyx
 ...

I usually have patience to look at up to 25 (1 screen).

25*25*25 = 15625 branch ends.

Just right to cover 2 levels of menu and package selection consisting
single page menu if package belongs to single branch for current debian.  

With 3 levels of menu and 3!=6 possible places to belong.

25*25*25*25 / 6 = 65104 >> 12000

I will add "autoload" as a tag so many packages are hidden under there.

> > > 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.
> 
>   I never claimed it was intuitive. :P

Yah. :-) I can tell you that even with [HELP] button, it is not very
intuitive for me.  But it will b useful :-)

Can you change [?] in New categorical browser to display this
information.  Also please add pointer to 'l' in menu.

Osamu
-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
        Osamu Aoki <osamu@debian.org>   Cupertino CA USA, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  "Our Priorities are Our Users and Free Software" --- Social Contract

Attachment: pgpiuQTyHrMpJ.pgp
Description: PGP signature


Reply to: