Request for more finely grained classification of packages
Hello,
It seems like a lot of focus is being put into making the Debian installation
somewhat less painful (with new frontends, configuration systems, and so on).
I'm only a lowly user :), but I'd like to make a request for something (well,
two somethings, but they're related) that I think would significantly increase
the ability of Normal People[tm] (I'm not one of these :) but I've helped
several of them install Debian and watched what's problematic) to handle
installing and maintaining Debian, and possibly make things easier for the rest
of us. It probably mainly requires changes to apt and dselect, but I'm not
really sure where to ask about it. So I'm sending it here.
First, some background: Debian potato currently has, according to apt-cache,
3730 packages. I may have (estimating generously here) around 30 extra
packages being picked up by non-standard entries in /etc/apt/sources.list.
That gives us 3700 packages. These packages are divided into sections such as
admin, devel, util, etc; sometimes a package is a single program, sometimes it
is a suite of programs, and sometimes it is merely a component of a suite which
may be installed with other, related programs. Some packages are not even
packages at all, but rather 'meta-packages' which declare dependencies on other
packages.
Now the problem: this is all well and good for those of us who have used the
system for a long time. But consider the problem of a new user: he (or she,
in the case of the most recent installation I assisted) is confronted [in
dselect] with a list of 3000 packages loosely grouped into categories based on
their type: admin tools, network stuff, mail stuff, news stuff, Web stuff, etc.
(and {non-free,contrib}/* , this is a nice distinction but somewhat confusing
to new people -- why are packages listed three times?) These distinctions
aren't really general enough; most users want stuff from about every section
except perhaps devel, hamradio, and interpreters. The result is that new users
are pretty much forced to thumb through all 3000 programs to find anything that
they will be interested in; not only that, but they have to make numerous
mental cross-references. When they see an ICQ client, for instance, they have
to consider: do I want an ICQ client? What other ICQ clients have I seen? How
does this compare? Further, there are suites of multiple related packages
which users could reasonably want to install as a group and almost certainly
want to group together conceptually; for example, the majority of Gnome tools,
the Python modules (which are spread all over the section tree if I remember
correctly), and the pieces of the old xbase. This is desirable for the sake of
modularity and flexibility, but an annoyance from the point of view of the
user. 'meta-packages' try to solve this but fall short -- if I uninstall the
Gnome meta-package, all of its 'contents' should be deselected.
(I should mention that even I get annoyed with the system as it stands and I
have very little trouble with dselect; I want to be able to conveniently list
all Python modules, or all ICQ clients and the current system is simply
inadequate for this)
I don't claim to have the One True Answer to that; what I'm going to suggest
is vague and quite possibly a suboptimal way to solve the problem. But I think
that the problem is very real and maybe even critical -- the current potential
for confusion is only going to increase as more packages go into the
distribution, and I don't know of any reason to expect the growth to slow in
the near future. I think that the most important thing is that some sort of
mechanism be implemented to acheive finer-grained classification of packages in
dselect.
To solve the problem of packages being classified too broadly, there are
basically two things that I want to do. First, I'd like to further separate
a package's classification from its location in the archive hierarchy (although
we could, I suppose, modify the hierarchy to support the new setup). The
'classification' of a package is its location in a sort of virtual hierarchy
which describes (sort of) what the package does. This hierarchy is displayed to
the user in dselect and apt; it is currently equal to the filesystem hierarchy
but perhaps it shouldn't be. Ignoring non-free and contrib for the time being,
instead of the current system of toplevel directories:
admin/
base/
doc/
.
.
.
x11/
I would like to see something like the following (a rough sketch with some
examples for each category -- more categories should probably be added :) ):
admin/
config/ <-------- linuxconf, dotfile-*
debian/ <-------- dpkg, apt, menu
misc/ <-------- stuff that doesn't categorize well--
eg, queue
monitor/ <-------- acct, gtop (maybe, see below)
network/ <-------- ipchains, etc.
priviliges/ <-------- makepasswd, sudo, secure-su
security/ <-------- tripwire
base <--- this is going to be problematic, perhaps it should not present in
the classification of a package. For example, ppp (as I noted above)
really belongs in net. On the other hand, many things in 'base' don't
classify well -- for example, base-files or ldso.
devel/
binutils/ <-------- nasm, binutils, bin86
buildtools/ <-------- make, autoconf
compilers/ <-------- gcc, pgcc
debian/ <-------- dpkg-dev, debhelper
debug/ <-------- gdb, ddd
interpreters/ <-------- python, perl, guile, ucblogo
editors/
emacs/ <-------- emacsen
misc/ <-------- ummm, no candidates offhand :)
programming/ <-------- Other editors primarily for programmers
(jed, joe?..I mainly know emacs and vi but
I see other programmers' editors in my
package list :) )
simple/ <-------- editors meant to be fairly simple
(eg, gxedit)
vi/ <-------- vi-derived programs
games/
arcade/ <-------- xpilot, koules
board/ <-------- xboard
misc/ <-------- *hack
puzzle/ <-------- gfpoken, etc
quake/ <-------- Crazy stuff from id
tetrisesque/ <-------- *tris
toys/ <-------- cthuga, synaethesia, xteddy
.
.
.
net/
ftp/ <-------- lftp, gftp, ncftp, ...
irc/ <-------- irc clients
mail/ v------------------------ Notice the subnesting
clients/ <-------- mutt. What else do you need? :)
lists/ <-------- mailman, berolist
misc/ <-------- fetchmail
mtas/ <-------- exim, postfix (maybe name it 'servers')
messaging/ <-------- ICQ, AIM, Linpopup, and Zephyr
news/
clients/ <-------- gnus, inn, whatever else there is
misc/ <-------- fetchnews?
servers/ <-------- [ I don't know about servers :) ]
remote-shell/ <-------- rsh, ssh, and friends (there are some
other programs in this area I think)
web/
browsers/ <-------- netscape, w3
servers/ <-------- Roxen, apache
x11/
base/ <-------- Really core x11 stuff: xauth,
/etc/X11/Xsession,. Maybe base/x11?
display-managers/ <-------- gdm, xdm, kdm, wdm
misc/ <-------- xtartan, xplanet (maybe in games/misc
or games/toys),
x2x
server/ <-------- xserver-*, xvfb
terminals/ <-------- xterm, Eterm, gnome-terminal
window-managers/ <-------- wmaker.
etc
A few things deserve special mention:
-> I think that perhaps almost all libraries should move to libs/ -- right
now there seem to be libraries scattered all over (for example, there are
image-loading libraries in graphics/ and popt is in devel/ ) -- these
consume time and aren't important for most users thanks to our packaging
system. Certainly not the -dev packages, which are often paired with them!
Libraries such as ccmalloc that are primarily intersting to developers
should be in libs/devel. (or should we make an exception for ccmalloc
and put it in devel/debug? :) )
-> The subnesting is probably not critical; if it's too much trouble to
rewrite programs to handle arbitrary subnesting we can just use a two-level
system; that's probably granular enough.
-> Each section should have its own description somewhere available to the
user; this is something I forgot to mention above, but the sections don't
really describe themselves. (yes, they seem self-evident, but you'd be
surprised -- especially things that most people want, such as
net/mail/clients; many people might not know what a mail client is and
having the text "Programs to read mail" clearly visible would be a world
of help)
-> We may still need a 'misc' section but use of it should be avoided at all
costs. (some stuff is probably going to end up there anyway :) )
-> non-us, contrib, and non-free should have similar (although less
populated :) ) hierarchies.
The idea should be to provide clear groupings and move from general to
specific stuff: x11 is for x11-specific utilities (such as window managers
or programs to do weird things: eg, x2x) window managers should get their own
section, as should other broad groupings of programs. More specific groupings
can get their own subhierarchies, but the following property should be
preserved to the best extent possible: no programs which are similar in
function should be placed in separate groups. In other words -- there are a
lot of cases at the moment (nothing specific comes to mind) where similar
programs are filed in different sections (eg, in x11, mail, and net) which
makes it a pain to track down all programs that do whatever they do.
Furthermore, 'end-user' programs, administrator-type programs, and
development programs should be separated as much as possible. I do all three
types of things to varying extents, but usually not at the same time; it's
annoying to have to page past lots of Web servers while looking for Web
browser.
I could keep going on and on here, but I'll stop in a second :) There's
one other really essential thing; we need a package-management interface that
will allow you *to collapse and/or hide these hierarchies*. Gratuitously
overwhelming the user with information is not cool (which is what this whole
suggestion is about :) ) and one really important way to help with this is to
let the user make stuff that he/she isn't interested in *go away* so that no
more mental CPU cycles are wasted considering it.
A possible implementation (this is the less interesting part in some
ways :) ) is simply to use the Section: field we have now but to change
policy to have a more expansive tree to place packages in (and have
relatively strict dictates about where stuff goes) So, for example:
Package: gaime
Version: 0.5.0-4
Maintainer: Daniel Burrows <Daniel_Burrows@brown.edu>
Section: net/messanging
.
.
.
Probably the distinction between priorities as a top-level attribute should
also be dropped -- in fact, the only important priority to me as a user is
Required vs Everything Else and the Required packages could be marked in some
other way.
Ok, I'll shut up on that topic. The other one is much more general, but
here's the idea:
We have a number of situations where a large number of packages depend on
a single set of 'base' packages or are otherwise conceptually related --
suites of packages and packages with optional pieces. I think that it should
be possible for the user interface to collect these packages and display them
as a group with a heading metapackage, eg:
[+] programming/
\
[+] interpreters/
\
[+] python/
| base (package python-base)
| curses (package python-curses)
| gtk (package python-gtk)
.
.
.
If I select 'python', either all Python packages should be installed
or (my preference) a 'recommended' set of Python packages should be installed.
If I deselect 'python', all Python packages should be removed.
Now, there are two obvious ways to implement something like this -- either
the 'meta-package' can list packages that it includes, or the included packages
can list what part of a meta-package they are. I prefer the second option, as
it is more flexible. A first approximation would be:
Package: python-gtk
.
.
.
Component-Provides: python.gtk
(maybe just Provides: ? -- but we might also want the normal Provides: )
Note that this is still not something dpkg really has to know about --
interdependencies amongst the components are declared as usual (although I
think Component-Depended for the stuff that must be installed when python/
is selected and Componenet-Recommeded for stuff that should probably be
installed would be nice, this is still an apt thing). That is, 'python' is
not even a package according to dpkg. It's just an entry in apt's namespace
that's a convenient way to group packages.
One last idea that crossed my mind whilst thinking about this: boot logos.
Some people have suggested that Debian have boot logos for the various daemons
that appear (I actually think this is a cute idea; I'd have to see it before
deciding whether to use it :) ) Should this be implemented, I assume that
there'll be a boot-logos package which provides the scripts to do this and
daemons that support it will add a boot logo to the files that they ship. For
people that use boot logos this is good. The rest of us will have to download
and store a boot logo for every package with an entry in /etc/init.d . A nifty
way to solve this is:
Package: lambdamoo-bootlogo
.
.
.
Component-Provides: lambdamoo.boot-logo
Package: boot-logos
.
.
.
Depends: *.boot-logo
This would require modifications to dpkg, though, which could be too messy to
implement.
Anyway, I've talked enough :) I hope you will at least consider some
breakup and componentization of the package hierarchy along these lines; it
would, in my opinion, be a major improvement to the Debian distribution.
Daniel
--
In dreams I crossed a barren land,
A land of ruin, far away;
Around me hung on every hand
A deathful stillness of decay.
And silent, as in bleak dismay
That song should thus forsaken be,
On that forgotten ground there lay
The broken flutes of Arcady.
-- Edwin Arlington Robinson, "Ballad of Broken Flutes"
Reply to: