Re: Re: RFC: Making mail-transport-agent Priority: optional
Neil Williams wrote:
> On Sat, 15 Oct 2011 22:29:56 +0200
> Andreas Barth <aba@not.so.argh.org> wrote:
> > * Neil Williams (codehelp@debian.org) [111015 22:23]:
> > > 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.
> >
> > "Standard" is just another word for "what someone expect so it's
> > considered as normal unix", which *is* a multi-user server.
> >
> > Perhaps the task isn't named perfect, but that's just what standard
> > is.
>
> If it was just a task used by tasksel, I'd be happy. The connotation of
> Priority: standard in debian/control is somewhat different and, to me
> at least, completely unnecessary.
>
> tasksel doesn't need anything in the Packages file, so why do we still
> retain Priority: in debian/control other than for Priority: required?
> The list of standard packages could just live in /usr/share/tasksel/ -
> only one place to change it.
>
> Why is it anywhere else?
As far as I know, Priority has the following non-cosmetic uses:
- d-i installs everything >= important by default.
- tasksel's standard task, selected by default in d-i, additionally
installs packages with priority standard.
- The Debian CDs and DVDs sort packages by priority so that the earlier
discs contain packages people will more likely want. Given that we
carefully try to ensure that standard plus the desktop task fits on
the first disc, and standard fits on the netinst disc, this mostly
means that priority optional comes before priority extra on the later
discs, for people who use discs for something other than initial
installation.
- Policy requires that packages not have dependencies of lower priority.
As far as I know, this requirement exists primarily to support the
previous point.
I don't know if Priority has any magic internal effects on the
dependency resolvers in apt and aptitude; for the purposes of the
discussion below I'll assume it doesn't.
Based on that, I do think we could reduce the number of distinctions in
Priority if we want to, without too much trouble. The distinction
between required and important doesn't really matter since we have
"Essential: yes"; a quick search shows that everything with priority
required either has Essential: yes or forms part of the dependency chain
of an essential package. (Oddly, the reverse doesn't hold, since apt
has priority important but Essential: yes; bug filed.) The distinction
between optional and extra doesn't seem that critical either.
So, we could comfortably pare down Priority to three cases: important,
standard, and optional. If, as you suggest, the task of determining the
contents of standard falls entirely to tasksel, then we could reduce to
just two priorities: important and optional. The distinction between
required/important and standard does seem useful ("working system"
versus "default, comfortable system"), though occasionally I wish for
the option to truly install the bare minimum set of packages needed to
fetch more packages over the network. (Arguably, the set of packages in
important could go elsewhere as well, since it just represents the set
of packages we consider too important to allow the user to deselect at
install time, such as packages needed for networking.)
> It would seem to make things a lot clearer for most people if
> the Standard Task was not linked in any way to Priority: * in
> debian/control.
Seems like a reasonable idea to me. I do think the contents of a
standard install should not depend on a pile of individual priorities
set by package maintainers.
> > > It appears to be based on an
> > > assumption that an experienced sysadmin will connect to the box and
> > > wonder where stuff has gone.
> >
> > Oh yes, that's the definition.
>
> Then should it not be renamed "Server" instead of Standard? We already
> have one of those, there's nothing to say that desktop cannot include
> some packages / tasks which are also in server, laptops too. Standard
> shouldn't be used in place of a shared task.
Agreed. Standard makes sense as a pile of tools which the system
doesn't need to function, but which fingers would stage an uprising
about if missing. I'd suggest moving other things to "Mail Server",
"Web Server", "Traditional UNIX Server",etc.
(Also, I feel that programs which simply provide a command on $PATH, and
don't install a daemon, init script, or similar, matter very little.
They still seem worth caring about to reduce the size of the standard
install, but they have far less impact than daemons like exim.)
> I think I'm going to have to put something on the Emdebian website
> about *not* choosing "Standard" when using the new ISO images using
> Debian Installer...
Hopefully removing exim will help there, but I do suspect that Emdebian
will always want less than the full set of "standard" or even
"important" packages.
> > > 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.
> >
> > Nobody claims that. If you don't expect the standard unix things,
> > then don't install standard. End of story.
>
> For non-server tasks I don't. I think there is a reason to not have
> server tasks in 'standard'. Quite why locales is considered to be in the
> same task list as bind9 is beyond me.
>
> It would be much more useful to be able to choose a task which brings
> in locales, file and gettext without also bringing in bind9, exim and
> kerberos IMHO.
Note that standard doesn't include the bind9 server, just utilities like
host and dig, and the libraries supporting them. Similarly, standard
doesn't include a Kerberos server or clients, just libraries needed by
programs in standard built with Kerberos support. It does, however,
include exim, but I'm working on that. :)
- Josh Triplett
Reply to: