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

Re: Aptitude, ARs

On Fri, Mar 14, 2003 at 11:08:37AM -0800, Osamu Aoki wrote:

> Thank you for your comments.  Although I do not agree with your
> suggested approach to solve this problem, your review on previously
> proposed menu organization ideas helped me.

> > There have already been done some proposals in this same list:
> > 
> > 1.- http://people.debian.org/~enrico/tagbk-draft.pdf (sent by Enrico Zini
> > to debian-devel in july last year)
> This is interesting reading for generic idea for organization of nodes.

Not just a reading: during the LCA 2003 I've adapted my C++
implementation of the algorithm to work with data from
/usr/share/aptitude/function_pkgs and produced an XBEL hierarchy to try
and navigate in the Galeon bookmark browser.

The results of the demonstration were generally considered interesting,
given that the current cathegory data was collected in a suboptimal way
(the function_pkgs has not been reviewed by the main public, and I used
some euristics to split the cathegories it contains, converting for
example "games-toys" in "games" and "toys").  The algorithm itself is
experimental and will probably need some tuning.

Aptitude has been deinstalled in my sid system because of libsigc++
dependencies and is not yet installable, so I can't try the "Categorical
Browser" you advertised in a previous post.  However, I've just
generated the test hierarchy using the function_pkgs package found in
the source package of aptitude (, and made it available on

To try it, start galeon, go into the bookmark browser and use the
"File/Import bookmarks..." function to add the generated tree to your
bookmark tree.  You can then navigate the hierarchy starting from the
newly added folder called "_top".

I've been silent after the LCA 2003 because we planned to open a
debian usability list on sourceforge and discuss all these issues (and
many more) there, but the list has not yet been opened, although it's
due to be quite soon.

In the meantime, since I see the issue is being approached, I'll be
more than happy to start working with you!

> > 2.- The menu code rewrite including it's new hierarchy. After all, it
> > resembles a proper division on Section/Subsection.
> Thanks for pointing out.  I was thinking about menu data entries as an
> alternate source too.  Problem is people does not put package in proper
> categories if we just set policy and expect things to happen.

We can always report bugs if things don't happen.

I'm interested in helping in the menu issue, too; I've offered help some
months ago, but I didn't get many answers.  There are some different
problems there though, like coping with the existing Gnome and KDE menus.

> > 3.- The bug #144046 lists some proposals on a multiviews-tree and keyword
> > based mechanism.
> Yes. I know.  Have you seen multi-view features in aptitude's "New
> Categorical Browser".  Keyword approach is interesting.  Hmmm...  This
> can be included during aptitude's database generation process.  Native
> support by aptitude is another agenda.  Thanks for reminding me.  
> Currently, Daniel manually collected overlapping key words into a single
> group attached to multiple tree branch.
> I will certainly steal some entry/keyword suggestions from bug #144046
> while using some idea from Daniel's entry.

I propose we group the many people that demonstrated interest in this
issue and join ideas and efforts.  I guess most of the interested people
can be found in #144046.

(BTW, why, even after my previous posts, nobody told me about #144046?)

> > 	Then by all means go ahead, however, it's like the task system, a
> > way to "hide" a problem: user's (at least common ones) cannot
> > navigate/browse our 9000+ packages with ease and be able to find what they
> > need.
> Yes.  Hiding with tunable threshold is my objective which task does not
> offer.

How do you plan to tune the thresholds, since this weighting is likely
to be strongly subjective?

> Anyway, I will focus on fixing this problem but in the way most
> extensible to accomodate possible future policy change.

Many ideas were collected in a BOF at the LCA 2003 for expanding the set
of package metadata.  I still have them here, waiting for enderboi to
bring that list online.



GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>

Attachment: pgpPAZkmzJp5A.pgp
Description: PGP signature

Reply to: