Javi,
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.
On Fri, Mar 14, 2003 at 09:01:51AM +0100, Javier Fernández-Sanguino Peña wrote:
> On Thu, Mar 13, 2003 at 01:43:51PM -0800, Osamu Aoki wrote:
> (...)
> >
> > It is kind of funny that you always start saying "I have proposed this
> > problem with MY solution long time ago with bug #xxxx". Please think
> > that why this bug has not been fixed after 1 year. Tell me what stalled
> > this progress? (Do not blame on the unwillingness of others. Start
> > from the fact that you *failed* to *persuade* them. Sorry for my harsh
> > words but let's find a solution here. I know chances of success for my
> > attempt here is also not very high either. It is a real challenge.)
>
> It's probably fixed because not enough people find it a worthwhile goal to
> fix it or some other things have higher priorities. I'm just asking to
> consider fixing this before doing other stuff. YMMV.
I know what I am bothered is an OLD problem. I certainly considered
policy approaches in the past.
If your assessment of situation is correct which I think is quite
accurate, there are not sufficient people interested on this subject to
be solved from policy end. This means I can not expect much progress on
this policy approach in short term. Even if we have policy change
today, it will take Sarge+ or Sarge++ to get that implemented in useful
shape. Effect of the policy change is very slow. This is too slow for
me.
I think, as a distribution, after d-i, package installers are the face of
"Debian". Improvement of aptitude is essential.
> > I think you are missing my intent of fixing these issues in aptitude. I
> > think first thing to do is to establish *proof-of-concept*
> > implementation of sorting category and keyword/attribute assignment.
> > That is what we are proposing here with aptitude.
>
> 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.
> 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.
> 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.
> (...)
> > > PS: And we _could_ use a similar division as those used by other
> > > distributions which have tackled the issue already and do have
> > > Sections+Subsections...
> >
> > Sure, but we need concrete examples or rule here. Can you point out
> > example? "like ..." is not enough. I need specific one for Debian.
>
> Sorry, I don't have time to work this out. But one could simply
> take a RedHat, SuSe and Mandrake CD and take a look at which applications
> they are shipping and how they get divided into sections/subsections. They
> have already worked (something) out. We could use it to our benefit. That's
> just IMHO but it should not be difficult to do (but it's not in my
> priorities list either).
>
> > I think it is easiest to communicate by implementing it in aptitude.
> >
> 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.
By the way, package number of 9000 is for woody. 12000+ packages may be
more accurate for testing/unstable archive as I checked last night.
iThis is why over 3000 are new packages which lacks aptitude "New
Categorical Browser" entry for Sarge.
Anyway, I will focus on fixing this problem but in the way most
extensible to accomodate possible future policy change.
Cheers.
--
~\^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:
pgpvg1w5RmdVe.pgp
Description: PGP signature