On Sun, 18 Jul 2010 15:16:49 -0700 Russ Allbery <r...@debian.org> wrote:
apologies for this one being so long... > Neil Williams <codeh...@debian.org> writes: > > > It is very worthwhile having a clear division between Required and > > Important. A typical bootstrap should include Required but there is > > no need for any of the important packages and any which may be > > useful can be added explicitly. > > That's probably part of what I'm missing; what's the purpose of > required in addition to essential plus dependencies? Required provides a general-case base for many situations but even this is too large a collection for some purposes. Required is a largely complete set, it is hard to bring in more than about 30% of the Required packages without bringing in the rest. Exceptions are probably gcc-x.x-base, bash and dash or dash and bash, debconf (because cdebconf should be possible instead) and e2fs* for SSD systems where ext* is a waste of time. Important adds nothing useful to that set - read as a *set* - although it does contain *individual* packages that are useful to cherry-pick, principally apt. A quick test gives Important as: adduser apt-utils apt aptitude bsdmainutils libbz2-1.0 cpio cron libcwidget3 debian-archive-keyring dmidecode libgdbm3 gnupg gpgv groff-base ifupdown iproute iptables iputils-ping dhcp3-client dhcp3-common isc-dhcp-client isc-dhcp-common logrotate libept1 libsigc++-2.0-0c2a libtasn1-3 libusb-0.1-4 man-db manpages module-init-tools nano libncursesw5 net-tools netbase netcat-traditional libnewt0.52 whiptail libssl0.9.8 libpopt0 procps libreadline5 libreadline6 readline-common rsyslog libslang2 tasksel-data tasksel libwrap0 info install-info traceroute udev vim-common vim-tiny wget libxapian15 Of those, aptitude and it's dependencies are not necessary (just nice to have sometimes), tasksel and dependencies should only be included when using D-I, whiptail and readline (and dependencies) are not always necessary, particularly when debconf is preset to non-interactive (like chroots) and having both vim and nano is just overkill. I like vim but even vim-tiny is not as small as it's name would indicate and yet not sufficiently useful, compared to vim-full, to be retained on many systems. > Policy defines required as: > > Packages which are necessary for the proper functioning of the > system (usually, this means that dpkg functionality depends on these > packages). Removing a required package may cause your system to > become totally broken and you may not even be able to use dpkg to put > things back, so only do so if you know what you are doing. Systems > with only the required packages are probably unusable, but they do > have enough functionality to allow the sysadmin to boot and install > more software. The only Important package which can be shoe-horned into such a description is apt. Required is reasonably OK at the moment, IMHO; the few packages that are unwanted are not that large. Important is just too large a set and contains packages that are simply not that "important" to everyone. On a strict reading of the above, I would regard only those packages utterly intrinsic to the unpacking of .deb files as Required - tar, ar, and coreutils (or a modified busybox). (Yes, I have got into a situation where a bootable system had no dpkg, no coreutils, no tar and no ar - just a busybox shell - the unmodified busybox from DI. That led to a reinstall. *That* is what I'd consider "totally broken".) ;-) As a case in point, I think Policy 2.5 has this bit wrong: "Systems with only the required packages are probably unusable, but they do have enough functionality to allow the sysadmin to boot and install more software." Systems with only the required packages installed can be fully usable - depending on the type of tasks expected of that system. The installed packages still include enough functionality to allow the sysadmin to boot and install more software. I might even file a bug report against debian-policy for that one. It's a subtle change but one that reflects the move towards making Debian a truly Universal OS, not just a desktop and server OS (which, IMHO, it was until, probably, Lenny). > This sounds quite a bit like the definition of essential, except that > required adds "allow the sysadmin to boot" and essential has the > special unconfigured requirement. .... yet no kernel package is Priority: required - nor should one be, even though it's not that common to boot a runtime system without a local kernel. > Hm. So are there packages that aren't usable until configured but > which should never be removed from the system? I guess that would be > the difference between required and the essential closure. Even dpkg can be removed from the system if the admin is sufficiently careful and uses a static configuration. (See Emdebian Baked [0]) These divisions are arbitrary and have been traditionally decided on the basis of our own desktop and probably server configurations. There are a lot more permutations now and the old dividing lines are only shades of grey IMHO. > > Please don't merge Important or lose the distinction between > > Required and Important - Required is sufficiently bloated already > > without adding Important. Far preferable (from an embedded > > perspective) to drop Important and make everything else into a > > default Priority (optional). > > Well, I was asking a question about the goals of the priority levels > in the abstract, not about what's currently classified there. The goals need to be redefined because the *understanding* of the current goals appears predicated on a desktop or heavyweight server implementation when Debian is increasingly being used in much more targeted ways. Even if such devices are gaining more file system space, that space should be restricted to user and application support data, *not* unnecessary OS components. Debian still has some way to go to being sufficiently slim to meet the expectation of a "Universal OS" because a truly universal OS will never get in the way of user requirements - and that includes not taking up available space with packages that perform no useful function on that specific type of device. > If we > merged required and important, obviously there's probably a lot of > stuff that's currently in important that should drop back a level to > standard. Yes. Aptitude for one - and all it's dependencies, along with vim-tiny. Although, see later, I think Priority: standard can go to /dev/null myself. > >> * Base installation. The smallest possible installation you can > >> put on a regular system and have a working and usable text-mode > >> computer on which you can install other things and which looks > >> like UNIX. This seems to be what Priority: important is supposed > >> to give you. > > > I disagree, Priority: required is all that is necessary for that > > purpose. > > You disagree that's what Priority: important is supposed to give you? Indeed. i.e. the packages currently specified as Priority: important are not "the smallest possible installation" - that set is Priority: required (and even that can be further trimmed), as outlined above. I think that the Base installation is what Priority: required is supposed to give us, albeit with apt added to Priority: required. (However, if you use apt to install all Priority: required packages, you always end up with apt installing itself anyway, so that point is moot.) > Important programs, including those which one would expect to > find on any Unix-like system. If the expectation is that an > experienced Unix person who found it missing would say "What on earth > is going on, where is foo?", it must be an important package. Other > packages without which the system will not run well or be usable must > also have priority important. This does not include Emacs, the X > Window System, TeX or any other large applications. The important > packages are just a bare minimum of commonly-expected and necessary > tools. > > That sure sounds like what it says. Or do you think our > implementation of important is buggy? Yes, our implementation is buggy because it appears predicated on desktop and server implementations only. > You're coming across as > disagreeing vehemently with me but being insufficiently clear for me > to be able to figure out what you're actually disagreeing with. :) There is nothing there about Priority important being a complete set but merely a range of packages which have some common ground. I'm disagreeing that the current list of packages deemed Priority: important all fit the above description - mainly because the meaning of the terms is vague and open to a lot of interpretation. "not be able to run well" - as what? desktop? server? router? kiosk? netbook? NAS? We cannot deal with a mythical person asking the "What is going on?" question if that person expects a desktop system from a NAS. The answer needs to be dependent on the kind of system - not all Debian systems can or should be the same. The current Priority groupings are too fat because our terms are too biased towards traditional Debian target systems. > There's an open Policy bug requesting clarification of the difference > between important and standard, and I admit I'm rather fuzzy on that > myself. I haven't delved into standard - the fact that python is "standard" is sufficient for me to not regard "standard" as anything of the sort and to treat "standard" == "optional". I mean, why is every "standard" Debian box meant to be an MTA and include both ftp and telnet clients as well as debian-faq and wamerican? Do we want exim4 on an OpenMoko phone or SLUG NAS? To me, the whole Priority: field is outdated and almost completely irrelevant to a large number of situations where Debian is commonly used. I agree that Priority: required is mostly OK (with above exceptions), but all other values I simply ignore when preparing both Debian systems and programs that create Debian systems. Yes, we need something like Priority: required and, on the whole, the current list of packages in that set isn't too far off IMHO. As for the rest, everything is optional in my book. i.e. Priority: could become a boolean field - it is either required or optional, any other value being handled as optional. [0] http://www.emdebian.org/baked/ -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
pgpFmhIcJ0ckZ.pgp
Description: PGP signature
