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

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

On Sun, Mar 16, 2003 at 12:55:12AM +0100, Enrico Zini wrote:
> On Sat, Mar 15, 2003 at 11:26:40AM -0800, Osamu Aoki wrote:
> 12585+ packages are an interesting problem which poses non trivial
> usability problems and calls for some research on information
> visualization techniques.

 Spend 20 seconds to assign several keywords to a package

 12585 binary packages translates
  12585 * (20/60) * (1/60) hours = solid 69 hours :-)

  It is non trivial.  (I guess Daniel spent at least 20 solid hour
  even with 10 sec/package speed to finish for woody)

Just to finish current one within current structure, I see over 20 more
hours to do it.  Long hours...  (If we go by source package there are
about 7000 packages in unstable)  *non trivial* for sure.

Anyway, Enrico, you seem to have lots of interesting ideas and programs
in terms of algorithm.  Before launching implementation, maybe we should
set "expectation" and "success criteria" for menu system from user's

Let's list wish list:
 0. As much entry shall be hidden and set by default to reduce clutter.
 1. I do not want to see all the library packages, task contents, -dev
    packages, -doc(s) packages, selection of virtualized packages or
    selection of l10n packages until I choose to change defaults.
 2. The package selection process should provide default automatically
    through the policy on the system. Things like choice of newest, 2nd
    newest or maturest version library shall be policy issue. So as
    whether corresponding -doc or -dev are installed or not.
 3. Recommend/suggests should have policy based defaults.
 4. There shall always exist a way to override policy for finer grain 
    admin control.
 5. If package offer alternative, they should be grouped and only
    display one entry with the highest score alternative one, such as vim,
    shall be chosen as the default over lower score nvi.  choice of
    xemacs21 or xemacs20 shall be governed by a policy similar to the
    policy for library (some people like latest, some wants rock
 6. Use some hushed database for the sake of speed :-)
 7. If the number of automatically chosen packages reach user set limit,
    user shall be given option to check dependency tree while presented
    with the fact "how many packages are selected by the auto-selection".
    User should be able to override auto-selection. (If threshold is set
    to 0, it is same behavior as dselect)
 8. If selection per screen is more than 50, we need finer category or
    we need some priority score system to reduce its display. 
 9. ... please add here :-)

Once we exhaust these wishlist and prioritize them, we write down how to
assign some key words/properties to each package.  Split the task, then
consolidate data to create final data.

Any suggestions for roadmap and expectation.
~\^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

Reply to: