Hi, (Sorry for not changing title in the previous post.)
APTITUDE is great :-)
We need to advocate it more.
Let me post my thought on aptitude based on my old private message to
Daniel here so everyone else (including Michael Banck) understands what,
I think, are the "Action Required" for aptitude.
Currently, about 2/3 of packages are properly assigned in "new
Categorical Browser". 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...
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.
I also see great possibility for aptitude's 'l' command which enables us
to limit scope of package displayed based on some rules.
If "Attribute:" entries are added to the function_pkgs files which gives
extra information unavailable in debian archive to each package, 'l'
option (or its new extension) can be used to scope package using
information in this field.
This does not solve problem of huge debian archive data size itself
which became to be unable to be handled on slower machine. Nor this
does not solve static nature of "Attribute" information which will be
obsoleted in a short period. But this approach does not require any
major change on Debian archive immediately. If it works, we can talk
more.
For example, this "Attribute:" field can include entries such as:
Language (ja, pt-br, ...)
Encoding (C, UTF-8, UNICODE, ...)
Auto installed or not (AUTO, )
Default for virtual packages (ALT, MAIN, ...)
Some kind of scores for the package importance with different focuses
(desktop, server, develop, ...)
My idea is to define token for each attribute which is followed by
numerical values (16 bit signed), something like,
"Attribute: token=[+|-]value, ...".
For example:
---------------
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.
I was thinking to include information such as "How many packages depends
on this package", "How many packages build-depends on this package",
"How many packages function as equivalent program as this package", ...
Once these features and tags are stabilized, user friendly "l" option
equation helper menu can be made for general use. It will be sweet.
In the long run, it is good idea to make these tags and categorization
as a policy item after general consensus. Also implementing a special
debian/control file editor which helps policy compliance will be
desired.
Current official categorization ("Section:" entries in debian/control or
one in aj's override file) is too coarse. Daniel's new categorization
is OK but I think there are still rooms for improvement.
As for Sarge, first thing is stick with Daniel's category and finish
categorization.
Also, for those packages with "alternatives", it will be nice to know
their alternative priorities in advance by including them in this
attribute field. Many ideas ... we need to prioritize them. Also we
need to design these features as very extensible and flexible one.
Lastly, we need some override control for the "pull" features for
"Recommend" and "suggests". Either by having break point for this chain
reaction or threshold for how many package an be pulled.
More user documentation is needed too.
This is my random thoughts on aptitude.
Thank you for reading this..
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:
pgp5A3cv_Pe6v.pgp
Description: PGP signature