Re: Request for more finely grained classification of packages
Sounds like you need Corel Debian Linux which offers this hierarchical
scheme of packages in our custom install option. Unfortunately, it won't
be released until November 1999 but it is certainly worth the wait.
Thanks.
Daniel Burrows wrote:
>
> 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"
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.orgbegin:vcard
n:Poon;Ming
x-mozilla-html:FALSE
url:www.corel.com
org:Corel Corporation;Emerging Technologies
adr:;;1600 Carling Avenue;Ottawa;Ontario;K1Z-8R7;Canada
version:2.1
email;internet:mingp@corel.com
title:Development Manager
x-mozilla-cpt:;-11072
fn:Ming Poon
end:vcard
Reply to: