"task" and beyond, aptitude is not solution
HI,
Thanks for information folks.
I realize that "aptitude" addresses some issues of task but does not
address all the issues with gap between 2 extremes, i.e.,
8700 packages
30 tasks.
De-selecting is good but not the complete cure for task.
I think remaining issues are
1. clutter of choice. (See previous message by Richard below. That
should address some clutter but it will be still too much for
the most uninitiated users.)
2. sheer number of packages scanned by apt which is beyond low end
machine.
3. no easy alternative choices for task entry
4. no threshold change for each task qualifying packages
As for 2, unless we are given some tool to filter package space in finer
grain than sources.list, my i486DX4 (20MB) is already very slow on
checking dependency. This will get worse since archive is growing and
unless we have some screening means to reduce the scope of archive,
there is no way out.
As for 3, finding ssmtp or nullmailer is not easy. Also postfix should
given position of alternative too.
Current package threshold of
Req
Imp
Std
Opt
Ext
is too rough. Also these nor section can not be used as screening
methods.
Most programs are Opt. Also some useful programs (ssmtp, nullmailer)
are (or should be) in hidden in Ext by policy due to its conflicts.
Unless we have nice alternative selection method, it is unpractical to
expect aptitude can solve problem.
On Wed, Feb 05, 2003 at 06:43:38PM +0100, Richard Atterer wrote:
> On Wed, Feb 05, 2003 at 03:29:22AM -0800, Osamu Aoki wrote:
> > My unelucidated thinking is if there is a field in control file which
> > gives *attribute* of package, it will make things much more easy if
> > package management tools use them properly. This is somewhat a extension
> > of task field.
>
> One attribute which I'd consider very useful: "auto-managed".
>
> Typically, run-time libraries and *-common/*-data packages would be
> declared "auto-managed". Such a package is not useful by itself, its
> features are only used indirectly by other packages which depend on it.
>
> A package selection tool would by default *not* list these packages. They'd
> get pulled in by other packages, and maybe they'd be deinstalled
> automatically once there are no other packages on the system which depend
> on them.
>
> This way, the number of displayed packages is cut down significantly, which
> helps the user find his way through the list of packages. A quick grep
> shows that about 25% of all packages could probably be declared
> "auto-managed"!
Yes. But that still leaves 6000 - 7000 choices. That is a lot.
Currently there is no navigation to find alternative package or choose
how much minor tools you want to install.
> (Further features would of course be nice: Override the attribute for
> certain packages so they *are* listed / won't be auto-deinstalled; only
> auto-deinstall if package has not been used for x days.)
--
~\^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: