[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Making mail-transport-agent Priority: optional

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

Attachment: pgpTBT5nCZRVg.pgp
Description: PGP signature

Reply to: