Tasksel's "standard" task (was: RFC: Making mail-transport-agent Priority: optional)
On Mon, 17 Oct 2011 16:55:09 +0200
Luca Capello <firstname.lastname@example.org> wrote:
> On Sun, 16 Oct 2011 00:48:11 +0200, Josh Triplett wrote:
> > Neil Williams wrote:
> >> On Sat, 15 Oct 2011 22:29:56 +0200
> >> Andreas Barth <email@example.com> wrote:
> >> > * Neil Williams (firstname.lastname@example.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.
> It seems there is *no* tasksel's standard task:
Hmm, thanks for checking, Luca.
> So I stand corrected by myself for the installation tests I did last
> week . And in this vision, what d-i shows as a tasksel's "standard"
> tasks is actually not a tasksel's task at all. Is this a bug?
I suspect it's tasksel or d-i doing stuff on the Priority:, so maybe
it's time to export that list from Priority: into a dedicated task.
Is there any other reason to have Priority: standard in debian/control?
In that process, the actual packages can be moved around and it would
make it easier for people like Emdebian to provide a replacement