On Sat, 15 Oct 2011 14:56:15 -0400 Joey Hess <joeyh@debian.org> wrote: > My other question comes from policy: > > `standard' > These packages provide a reasonably small but not too limited > character-mode system. This is what will be installed by default > if the user doesn't select anything else. It doesn't include > many large applications. > > As I read this, it would be legal for tasksel, when the user selects the > desktop task, to *not* install standard, or not all of standard. It > could, for example, decide to drop the MTA. I'm curious what the > reaction to that would be, in both this specific and the general case. > Is it a compromise that allows us to keep standard full of unix goodness > while still catering to the desktop, or a greedy power grab? > > (Other examples of the general case would be a Freedombox task that > didn't install a MTA, since the freedombox devs have decided to use some > other inter-user communication, IIRC -- or a specialized Debian Pure > blend that chose to not install standard at all.) It's quite common with embedded systems to only select Priority: required and then a carefully hand-picked set of packages from anywhere relevant in main. "Priority: standard", MTA, MUA, it really doesn't matter in the slightest. If some things don't work, work around it or find a package which does work. It's not worth worrying about and it's not that specialised. As part of this, Emdebian provides cut-down tasks which tasksel can use. I see no reason why those would not be compliant with Policy just because no MTA is included. The problem with "Standard" is that it is currently (and heavily) biased towards multi-user servers and most of the replies in this thread which decry the absence of an MTA would appear to come from those principally concerned with servers. It just doesn't fit with desktop users or embedded users. The test in Policy just seems wrong - in definition or in application I really don't think it matters which. It appears to be based on an assumption that an experienced sysadmin will connect to the box and wonder where stuff has gone. That *must* be context-sensitive - many routers are Unix / Linux - some may use .deb packaging systems (at least in the programming stage). Nobody would expect those to have ALL the packages from Priority: standard packages from the full Debian main archive. Debian is just too fat for that. Please, stop basing the judgement on MTAs on the use case of a multi-user server. Debian pushes itself as The Universal OS - our tests and assessments must be Universal too. The consensus here is clear - having an MTA as Priority: standard is only useful to a subset of interested parties and it actively hinders other subsets of interested parties. There needs to be another way of doing this. If there is no sane default for a particular choice, the choice needs to be retained and no default asserted (cribbed from the debconf docs). A no-op MTA is still not a useful choice for embedded systems. Priority: standard doesn't currently match The Universal OS and - as defined - never could. The decision about whether some package is missing MUST be context-sensitive. Context of usage, context of deployment, context of access. If a device has no external connectivity it cannot possibly matter that it does not have an MTA installed. It is still running Debian and that use of Debian cannot possibly be considered as breaking Debian Policy for that way lies madness. Next thing we'll have Policy mandating that any device running Debian has to have an ethernet card. Breaking news: many devices (including commercial machines currently on sale for real money on the open market) are running Debian but have never seen eth0 or friends but real people still want them and pay good money for them - usually in preference to machines which do have unnecessary hardware fitted. The one I'm thinking of also has no MTA and has never needed one. Users don't miss it because there is no use case for it on such machines. In fact, putting an MTA on such machines could conceivably hurt sales. About the only packages which most people truly would notice missing are those with Essential: yes and an MTA is definitely, absolutely, unthinkable in Essential. Even the list of packages in Essential is context sensitive - Emdebian doesn't retain "Essential: yes", including allowing systems which don't have apt or dpkg installed on the final system, let alone stuff like adduser, netbase of libdb* [0] Priority: Standard just doesn't matter any more. It is already irrelevant to those who need to ignore it, like Emdebian. If we need to adapt the tools to not care about Priority: standard and treat it as Priority: optional then let's do that. The line between Priority: optional and Priority: extra already appears largely arbitrary - more useful where it is flouted than where it is followed. While we're about it, lose Priority: optional, extra & standard and just have "Priority: required" and nothing else. I do mean nothing else too - the field either exists in debian/control as Priority: required or it is entirely absent. Any other value is already meaningless. Then we can decide whether we need Priority: required AND Essential: yes or just one value which tools like debootstrap, multistrap and Debian Installer can use consistently. Put it this way, nobody who is pushing for exim to remain in Priority: standard here gives two hoots over the fact that build chroots don't have an MTA. Of course not. It would be madness to expect an MTA inside a pbuilder clean chroot. A build chroot is a different use case. Emdebian represents a few different use cases. Desktop can be a couple of different use cases, depending on the experience levels of the desktop user and their expectations. If our tools cannot cope with the reality of how Debian is ACTUALLY used then we need to fix the tools and we need to fix Policy. Use cases are more important than Policy and more important than defaults. Policy exists to reflect the actual use of Debian. It is not a stick to beat those who *need* something different. This thread has gone on long enough already and I maybe I've added this all too late for it to be noticed amongst the other arguments and replies. Even so, a Universal OS cannot expects defaults for one use case to be acceptable for all use cases. Where no default can satisfy all use cases, the default cannot be retained. It is not about whether one use case involves "obsolete" this or whether it's outside your personal experience / comfort zone. Tough - that is not sufficient reason to hinder the use of Debian in such use cases. Debian IS used in a wide variety of contexts and our Policy *must* reflect this and must *not* get in the way. Let's fix the tools and forget the idea that an MTA is anything other than something that some use cases would require and some would not. An MTA is no different to a database or a web server or web browser or text editor. Installing or not installing one is a choice which has no right answer and Debian cannot afford the arrogance of asserting a default where none exists. [0] http://www.emdebian.org/baked/ -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpa9msli7Nxo.pgp
Description: PGP signature