Re: Tasks policy

[Anthony Towns]

On Tue, May 08, 2001 at 11:04:34PM -0400, Joey Hess wrote:
> Anthony Towns wrote:
> > Or moving them into the task package themselves, but not in the control
> > record? Or shall we just forget I suggested that originally.
> Well, I had. 

Well, it's possible I wasn't explicit enough. What I said was:

] This was discussed on -devel just after potato released, I think consensus
] was that we should use override files to populate these fields, rather
] than letting maintainers add their own packages directly to tasks. I'm
] not sure if we came to a consensus about how these override files would
] be maintained though (or who by: ftpmaster? -boot? the individual task-*
] maintainers?). It's probably best to put it in boot-floppies CVS, and have
] dinstall use that.

It's not remotely difficult to put the overrides in the dinstall
database where they can only be modified by ftpmaster, or to have the
dinstall cronjob update from boot-floppies CVS, or to extract them
automatically from individual task.debs direct from the pool. I still
think boot-floppies CVS would be the best compromise between ease of
access (since all developers have access to it, all maintainers pretty
much do too...) and ease of implementation (cvs checkouts are pretty
straightforward to automate).

But hey, easier to jump off the deep end than try working out the best
solution or building consensus, right?

Now that www.d.o is back up, I'll again cite the URL for the discussion
we had about this: http://lists.debian.org/debian-devel-0008/msg00700.html.
Some others of note:

http://lists.debian.org/debian-devel-0008/msg00711.html
http://lists.debian.org/debian-devel-0008/msg00700.html

See particularly the last three paragraphs of that last one.

> That's a reasonable alternative. Oh, except, I seem to remember you wanted
> to use some special-purpose field for it, when we again have perfectly
> good general purpose fields, Suggests and Recommends, that already do the 
> same thing.

Except they don't. Recommends is (quite reasonably) treated exactly the
same as Depends by dselect, and even missing suggests are complained
about ocassionally.

If I've suggested anything specific at all, btw, it wasn't anything in
their control file, but rather an extra file in /usr/share/doc or similar.
*shrug*

> > > * Eliminate all usefulness of tasks except when manipulated by one 
> > >   single special purpose tool (tasksel). (This includes making it
> > >   impossible to install a task and receive bugfix upgrades to it later.)
> > Yeah, because hey, if the tools aren't written now (or at the very least
> > mandated by policy) it'll be impossible to ever write them in future.
> I think it very unlikely that we will ever get support for some hackish
> field only used by task packages into Dselect, and Dpkg, and Apt, and
> Aptitude, and Deity, and Red Carpet and ...

Yeah, because those maintainers care a whole lot more about whether
something's inelegant rather than whether or not it works. Better to
not let people manage tasks at all than to do *that*.

> > > AJ asked for a concrete counterpropsal, and this is mine: If you really
> > > want to do this, just go back to Bruce's system. Redo it so it's not so
> > > blasted ugly and confusing, fix the self-destructive aspect, but use the
> > > same idea. Which likely means just hardcoding the tasks and what
> > > packages comprise them in tasksel, and when a task is selected, have apt
> > > install all available packages that are in the task.
> > "Forget all the code that exists and is working right now, and rewrite it
> > based on this old code that everyone's forgotten."
> Bruce's stuff was not so bad. Aside from being a rushed implementation,
> the idea was pretty good.
> see shy jo, ignoring certian nuances

Let me spell it out for you then: there is nothing concrete about
unwritten code.

If you'd wanted to get this fixed in your own special way, you've had nine
months to work out what you want. You've had nine months to reconsider
your agreement to the "Task:" idea. You've had nine months to go out
and implement something. But you didn't, so eventually I went out and
did what we'd discussed on -devel nine months ago. And now, of course,
you've decided that it offends your sense of aesthetics, and therefore
must absolutely *never* happen, and that I'm a completely unreasonable
little bigot for daring to propose such a thing.

Am I misreading something here? Is there something that tasks are
currently useful for that a combination of "Task:" fields and non task
metapackages doesn't work for? If so, there's a real problem with this
solution that needs to be fixed, and you're welcome to ignore any and
all insinuations so we can get on with that.

If not, though, are you seriously exaggerating a difference in taste
and perhaps some wishlists that no one's been bothered enough to try
implementing to the whole proposal being based on (how did it go again?)
"a horrid assumption, [that] says b

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> Or moving them into the task package themselves, but not in the control
> record? Or shall we just forget I suggested that originally.

Well, I had. 

That's a reasonable alternative. Oh, except, I seem to remember you wanted
to use some special-purpose field for it, when we again have perfectly
good general purpose fields, Suggests and Recommends, that already do the 
same thing.

> > * Eliminate all usefulness of tasks except when manipulated by one 
> >   single special purpose tool (tasksel). (This includes making it
> >   impossible to install a task and receive bugfix upgrades to it later.)
> 
> Yeah, because hey, if the tools aren't written now (or at the very least
> mandated by policy) it'll be impossible to ever write them in future.

I think it very unlikely that we will ever get support for some hackish
field only used by task packages into Dselect, and Dpkg, and Apt, and
Aptitude, and Deity, and Red Carpet and ...

This is why I have been trying to generalize the thing all along. A more
general purpose field will be more generally used, and so people will
have more incentive to implement it. Plus, it probably solves some other
problems out side of task space.

> > AJ asked for a concrete counterpropsal, and this is mine: If you really
> > want to do this, just go back to Bruce's system. Redo it so it's not so
> > blasted ugly and confusing, fix the self-destructive aspect, but use the
> > same idea. Which likely means just hardcoding the tasks and what
> > packages comprise them in tasksel, and when a task is selected, have apt
> > install all available packages that are in the task.
> 
> "Forget all the code that exists and is working right now, and rewrite it
> based on this old code that everyone's forgotten."

Bruce's stuff was not so bad. Aside from being a rushed implementation,
the idea was pretty good.

-- 
see shy jo, ignoring certian nuances

Re: Tasks policy

[Joey Hess]

> > Using a dependency field for this would mean you couldn't create a new task
> > without NMUing every package you intend to put in that task.

Or we could, *gasp*, _ask_ the maintainers to add the task to their
packages Enhances field. Most maintainers will probably jump at the
opportunity to have their package be on the fast track to user
installation. If a maintainer doesn't want that, or is too busy or MIA
to deal with it, do we really want their package being installed by
thousands of newbies?

-- 
see shy jo

Re: Tasks policy

[Anthony Towns]

On Tue, May 08, 2001 at 10:34:26PM -0400, Joey Hess wrote:
> * Move control of what packages a task includes out of the hands of the
>   creator of the task, and into the hands of people who have commits to
>   some cvs repository somewhere[1].

Like boot-floppies CVS which every developer and a few non-developers
have commit access to?

Or moving them into the task package themselves, but not in the control
record? Or shall we just forget I suggested that originally.

Yes, clearly it's a power trip and I don't trust anyone else. Why,
I'm evil and thoughtless and just plain baaad.

> * Eliminate all usefulness of tasks except when manipulated by one 
>   single special purpose tool (tasksel). (This includes making it
>   impossible to install a task and receive bugfix upgrades to it later.)

Yeah, because hey, if the tools aren't written now (or at the very least
mandated by policy) it'll be impossible to ever write them in future.

> AJ asked for a concrete counterpropsal, and this is mine: If you really
> want to do this, just go back to Bruce's system. Redo it so it's not so
> blasted ugly and confusing, fix the self-destructive aspect, but use the
> same idea. Which likely means just hardcoding the tasks and what
> packages comprise them in tasksel, and when a task is selected, have apt
> install all available packages that are in the task.

"Forget all the code that exists and is working right now, and rewrite it
based on this old code that everyone's forgotten."

Feh.

Cheers,
aj, getting fed up with trying to help

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpQ6FBKcMoaF.pgp
Description: PGP signature

Re: Tasks policy

[Joey Hess]

It occurs to me that what AJ's trying to do and its results can perhaps be
restated as follows (with apologies to AJ -- you have the best of
intentions):

* Move control of what packages a task includes out of the hands of the
  creator of the task, and into the hands of people who have commits to
  some cvs repository somewhere[1].
* Eliminate all usefulness of tasks except when manipulated by one 
  single special purpose tool (tasksel). (This includes making it
  impossible to install a task and receive bugfix upgrades to it later.)

But the only real differences between this proposed system and the system
Bruce wrote hurredly over Xmas for hamm or so are:

* In this system, we have these useless task-* packages cluttering up tools
  that cannot use them, while in Bruce's system, the tasks were hidden
  out of the way.
* Maintainers of task packages do get to provide a description of the
  task. In AJ's system, that's really all maintaining a task package means
  -- you maintain a package description, and nothing more.
* In Bruce's system, the task selector self-destructed and was not
  callable after install.

AJ asked for a concrete counterpropsal, and this is mine: If you really
want to do this, just go back to Bruce's system. Redo it so it's not so
blasted ugly and confusing, fix the self-destructive aspect, but use the
same idea. Which likely means just hardcoding the tasks and what
packages comprise them in tasksel, and when a task is selected, have apt
install all available packages that are in the task.

If we need a quick fix for the task problem in time for the freeze, this
is it. 

-- 
see shy jo

[1] The more I think about it, the more the reasons for this incense me.
All this talk of overrides files has the unstated assumption that we
cannot simply file bugs on packages, and get their maintainers to
add the appropriate Task: or Enhances: or whatever fields. This is a
horrid assumption, and it says bad things about either the state of
Debian or the assumptee.

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> On Tue, May 08, 2001 at 03:24:33PM -0400, Joey Hess wrote:
> > Anthony Towns wrote:
> > > Task: headers are more akin to Section: headers than Recommends:. Both in
> > > that people really ought to be able to just uninstall a package if they
> > > don't like it, and in that the complexity of dependency specifications
> > > just isn't warranted.
> > Have you thought at all about renaming Task: to Enhances:? 
> 
> Using a dependency field for this would mean you couldn't create a new task
> without NMUing every package you intend to put in that task.

If we're intending to use a small number of tasks, then that should not
be a big deal, since new task creation would be rare.

Also, it's surely possible to make whatever Packages file creation overrides
mechanism is developed just _add_ the task packages to existing Enhances
fields, preserving whatever else might be there.

-- 
see shy jo

Re: Tasks policy

[Joey Hess]

Jason Gunthorpe wrote:
> I would prefer if Enhances remained with it's original purpose: to
> maintain the idelogical purity of main but still allow recommends/suggests
> like relations to point into non-free.

Eh? Enchances purpose is to say "hey, even though package blah doesn't
know about me, I'm here, and I make package blah better!"

The political details which lead to its implementation are of no
consequence, just as whatever details lead to the implementation of
Suggests are of no consqeuence -- we have the field, it has a clearly
defined meaning, go use it as you will or as policy dictates.

> Task-membership headers should ultimately have a different meaning and
> different operation from Enhances.

I don't see it.

-- 
see shy jo

Re: Tasks policy

[Jason Gunthorpe]

On Wed, 9 May 2001, Anthony Towns wrote:

> On Mon, May 07, 2001 at 04:05:14PM -0400, Joey Hess wrote:
> > I don't recall a discussion of or decision on using overrides files.
> 
> Well, uh, you were in it...
> 
> "Overrides files" may not be quite the most accurate way of expressing it.
> Certainly, I don't mean overrides files that ftpmaster takes care of.

If it is possible to do it without override files then that should be the
prefered solution.

Otherwise getting the Task: information reliably into the status file will
be very hard and I think having task information there will be very
important in future.

Jason

Re: Tasks policy

[Anthony Towns]

On Tue, May 08, 2001 at 03:24:33PM -0400, Joey Hess wrote:
> Anthony Towns wrote:
> > Task: headers are more akin to Section: headers than Recommends:. Both in
> > that people really ought to be able to just uninstall a package if they
> > don't like it, and in that the complexity of dependency specifications
> > just isn't warranted.
> Have you thought at all about renaming Task: to Enhances:? 

Using a dependency field for this would mean you couldn't create a new task
without NMUing every package you intend to put in that task.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgp4m2V1tB67T.pgp
Description: PGP signature

Re: Tasks policy

[Jason Gunthorpe]

On Tue, 8 May 2001, Joey Hess wrote:

> Have you thought at all about renaming Task: to Enhances:? Dpkg already
> has some limited Enhances support, the two fields really have very close

I would prefer if Enhances remained with it's original purpose: to
maintain the idelogical purity of main but still allow recommends/suggests
like relations to point into non-free.

Task-membership headers should ultimately have a different meaning and
different operation from Enhances.

BTW, I don't see enhances in the dpkg 1.9.4 changelog..

Jason

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> Remember: the point of tasks is to make the initial install simpler,
> so that people can get started on Debian without having to wade through
> dselect.
> 
> So it's not a problem if *nothing* other than tasksel can handle
> installing and removing tasks elegantly yet.

Sure, but it's a problem if the way we reimplement tasks is not
something other tools can eventually handle elegantly. I don't want to
see tasks be something hackish that is bolted onto the side of Debian, I
want to see them cleanly integrated and supported by as many tools as
possible.

> Task: headers are more akin to Section: headers than Recommends:. Both in
> that people really ought to be able to just uninstall a package if they
> don't like it, and in that the complexity of dependency specifications
> just isn't warranted.

Have you thought at all about renaming Task: to Enhances:? Dpkg already
has some limited Enhances support, the two fields really have very close
if not identical meanings, and perhaps other dpkg frontends will one day
support Enchances, giving us task support for free. (I would really like to
be able to continue to use tasks in dselect, even though this is not thier
primary purpose. Dselect is still an alternate installation path that you
can choose instead of tasksel.)

If tasksel just starts looking at Enhances fields for tasks, we can
simply make the policy say that you cannot add a Enhances: task-* to a
package without asking the relevant authority.

-- 
see shy jo

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> > of re-overloading the package name. I think all those names are very, very
> > ugly. Wouldn't this be nicer --
> > Package: task-desktop
> > Tasksel-Section: user
> > Package: task-web-server
> > Tasksel-Section: servers
> 
> Well, I mentioned somewhere having a separate section for tasks. We could
> have more than one, and make it:
> 
>   Package: task-desktop
>   Section: user-tasks
> 
>   Package: task-web-server
>   Section: server-tasks

I would prefer something like this.

> > It's worth noting that for a good 3 or 4 months after potato's release,
> > new installs that used tasksel did not get emacs or tex, or anything
> > else in standard,
> 
> (Note that everyone who wanted TeX probably chose "task-tex" anyway)

Well, ok, but nobody complained about a missing task-emacs anyway.

-- 
see shy jo

Re: Tasks policy

[Anthony Towns]

On Mon, May 07, 2001 at 04:05:14PM -0400, Joey Hess wrote:
> I don't recall a discussion of or decision on using overrides files.

Well, uh, you were in it...

"Overrides files" may not be quite the most accurate way of expressing it.
Certainly, I don't mean overrides files that ftpmaster takes care of.

Unfortunately www.debian.org seems to be down, so I can't cite a url for
the discussion from a while ago, but the summary is basically that during
the freeze (ie, when I start removing packages left right and centre),
it's very easy for a task to get broken if task-membership is specified
as part of the task. If, instead, it's specified as part of the package
that's in the task, once the package is removed, the fact that it was
meant to be in the task disappears too, and fewer things break.

On the other hand, the way tasks currently work, with a single person
choosing which packages go in a task works fairly well (as you've said),
so that's something worth preserving. The way we can preserve that is
with override files.

> I also don't understand why this new Task: header is being introduced.

I'd encourage you to reread the thread from last year. I posted a URL
earlier in the thread.

> > * tasks should be priority optional (and thus packages in
> >   tasks should be priority optional),
> I think you mean the packages in a task should be option or higher (not
> extra), right?

Well, whatever. If they're standard or higher, they'll be installed
anyway, so it doesn't much matter. But yeah, that's all I was getting at.
It also brings into play the "don't Conflict: with other things" rules
from elsewhere.

> > * tasks should follow a naming convention so they can be organised
> >   better by tasksel. Probably:
> > task-devel-{c,c++,objc,haskell,...}
> > task-lang-{german,french,japanese,chinese,...}
> > task-server-{web,news,mail,database,dns,...}
> > task-user-{desktop,office,games,junior,...}
> > task-hware-{dialup,printer,laptop,...}
> Well we could let tasksel use the Section field, or some new field instead
> of re-overloading the package name. I think all those names are very, very
> ugly. Wouldn't this be nicer --
> Package: task-desktop
> Tasksel-Section: user
> Package: task-web-server
> Tasksel-Section: servers

Well, I mentioned somewhere having a separate section for tasks. We could
have more than one, and make it:

Package: task-desktop
Section: user-tasks

Package: task-web-server
Section: server-tasks

> Or even (why overload package the field at all) --

...because we're already doing it, and because it helps separate tasks
in existing UIs.

> Or even this (the only problem with it is that our current set of
> sections is so limited and hard to change) --

Sections are adminned by overrides by ftpmaster. There just needs a
good reason to create a new one (well, and some patience), it's not
really difficult.

> It's worth noting that for a good 3 or 4 months after potato's release,
> new installs that used tasksel did not get emacs or tex, or anything
> else in standard,

(Note that everyone who wanted TeX probably chose "task-tex" anyway)

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpGrjP96SYSP.pgp
Description: PGP signature

Re: Tasks policy

[Anthony Towns]

On Tue, May 08, 2001 at 12:19:20PM -0400, Sam Hartman wrote:
> > "Anthony" == Anthony Towns  writes:
> Anthony> You
> Anthony> check the code out from CVS, or do an apt-get source, you
> Anthony> write the code, and you send it to Randolph. It doesn't
> Anthony> need discussion here.
> I resent the implication that I'm responsible for fixing any problem
> that I discover.

Eh?

Seriously, it's quite easy. That's how "Task:" got implemented. I ran
"apt-get source", read the code 'til I understood it, implemented it,
did some testing, sent the patch to Randolph, and it got into the archive.

> I believe there is value in pointing out a problem
> report even if you don't have the resources to fix it.

What do you mean you don't have the resources to fix it? The code's all
right there. There're debuggers, and compilers and everything. There's
no licensing restrictions in your way. There's not even any controversy
about whether it'd be a Good Thing. It's not even hard.

(If you're trying to say you don't have the skill to fix it, then, quite
frankly, you probably shouldn't be trying to insist on what others should
be doing.)

> Anthony> Not really. Frontends should do whatever their authors
> Anthony> deem appropriate and have time to implement. If you want
> Anthony> to send in patches, or write your own frontend, more
> Anthony> power to you. It's not policy's place to say anything
> Anthony> about what features you should and shouldn't implement
> Anthony> though.
> I disagree in general; [...]

That doesn't really surprise me. It's much more fun to disagree about
things than to fix them. Even when it's not actually easier.

For reference:

--- tasksel-1.1/tasksel.c   Tue Apr 24 16:35:07 2001
+++ tasksel-1.2aj/tasksel.c Wed May  9 02:56:26 2001
@@ -176,6 +176,21 @@
   }
 
   tasklist = tasks_enumerate(&tasks);
+  if (noninteractive) {
+for (;optind < argc; optind++) {
+  /* mark task argv[optind] for install, if it exists */
+  int i;
+  for (i = 0; i < tasks.count; i++) {
+if (strcmp(tasklist[i]->name, argv[optind]) == 0) break;
+  }
+  if (i == tasks.count) {
+printf("E: %s: no such task\n", argv[optind]);
+  } else {
+tasklist[i]->selected = 1;
+  }
+}
+  }
+
   if (r == 0) {
 r = doinstall(tasklist, tasks.count,
  pkglist, (installreqd || installimp || installstd 


Getting a nice command line, rather than just the simplest to implement
is left as an exercise to the interested reader.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpilQ6y7A3Eg.pgp
Description: PGP signature

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> So, here's the deal. We need to get a proper policy for tasks fairly soon.

Amen.

> tasksel in sid supports a "Task:" header for packages so we can be a
> little more flexible than having every task- depend on everythig in it.
> This was discussed on -devel just after potato released, I think consensus
> was that we should use override files to populate these fields, rather
> than letting maintainers add their own packages directly to tasks. I'm
> not sure if we came to a consensus about how these override files would
> be maintained though (or who by: ftpmaster? -boot? the individual task-*
> maintainers?). It's probably best to put it in boot-floppies CVS, and have
> dinstall use that.

I don't recall a discussion of or decision on using overrides files.
While it seems that letting developers create task packages willy-nilly
with no rules or supervision has been a disaster, the overall quality of
the dependnaices in individual tasks is ok, so I see no need to have
centralized control over that. Bug reports suffice. So no need for overrides
files.

I also don't understand why this new Task: header is being introduced. I
mean, I understand why you don't want to use dependancies. But why not
let tasks use Recommends and Suggests in a sensible fashion, and simply
make tasksel install all packages listed in either field by a task package?
This would make tasks usable in eg, dselect and any other decent apt
frontend, and it wouldn't add a new, seemingly hackish field.

>   * tasks should be priority optional (and thus packages in
> tasks should be priority optional),

I think you mean the packages in a task should be option or higher (not
extra), right?

>   * tasks should follow a naming convention so they can be organised
> better by tasksel. Probably:
>   task-devel-{c,c++,objc,haskell,...}
>   task-lang-{german,french,japanese,chinese,...}
>   task-server-{web,news,mail,database,dns,...}
>   task-user-{desktop,office,games,junior,...}
>   task-hware-{dialup,printer,laptop,...}

Well we could let tasksel use the Section field, or some new field instead
of re-overloading the package name. I think all those names are very, very
ugly. Wouldn't this be nicer --

Package: task-desktop
Tasksel-Section: user

Package: task-web-server
Tasksel-Section: servers

Or even (why overload package the field at all) --

Package: desktop
Task: yes
Tasksel-Section: user

Package: web-server
Task: yes
Tasksel-Section: servers

Or even this (the only problem with it is that our current set of
sections is so limited and hard to change) --

Package: desktop
Task: yes
Section: user

Package: web-server
Task: yes
Section: servers

>   * we should have tasks specifically for emacs and tetex (even though
> both could be replaced by a wordprocessor in task-office, say).
> possibly:
>   task-sware-{tetex,emacs}
> and require any additional tasks like this get run through policy
> first. If nothing else, historical reasons are a good argument
> for tetex and emacs, and are obviously immune to slipper
> slopes. :)

It's worth noting that for a good 3 or 4 months after potato's release,
new installs that used tasksel did not get emacs or tex, or anything
else in standard, and that although people eventually complained about
other packages in standard not being installed, I never saw a single
complaint that those two were missing. After all, it didn't affect
upgrades, and I guess people who wanted emacs had no problem with using
apt afterwards.

-- 
see shy jo

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> > Would it not be much easier for the task packages _themselves_ to
> > contain Task: fields, instead of the individual packages, which would
> > function like weak Recommends: fields: 
> 
> Not really. The code's already written to do things the other way around,
> and the main point of "Task:" fields being in the package is so that
> packages can be removed from the archive without breaking any tasks they
> might be a part of.

I recently sent a mail questioning the Task: field. Seems I have
misunderstood (I thought it was intended to be a field in task packages,
listing the packages in the task). Now that I understand, I support Aj's
proposal wholeheartedly, except my thoughts about using sections to
organize tasks, rather than overloding the package name, still stand.

-- 
see shy jo

Re: Tasks policy

[Joey Hess]

Anthony Towns wrote:
> You can always run tasksel, select the task, and go "Ok", instead of using
> "apt-get install ..." though. Making "tasksel install server-dns" just go
> ahead and install the task, bypassing the UI, would be fairly simple too.

Another option would be to add real reverse dependancy support to apt
(a Task: field is really a reverse dependancy, if you get what I mean).
Reverse dependancies have other uses, and the lower in the package
manager stack they are supported, the better.

-- 
see shy jo, cringing at the concept of a package manager stack, but
that's what we have now

Re: Tasks policy

[Sam Hartman]

> "Anthony" == Anthony Towns  writes:
>> Yes, that was the original point of tasks.  However, tasks are
>> also used today by people who want to get a set of software
>> installed after the initial install.  [...]

>> Yet I understand we have finite time.  Would it be reasonable
>> to get tasksel install task-name added as a command line
>> invocation for people to use in scripts

Anthony> I'm not sure what scripts have to do with anything, but
Anthony> adding a command line option is entirely trivial. 

So, it is very annoying to write a script to go into tasksel, move to
the appropriate task, select it and go down to OK.  If I want to install a task 
as part of some management script,
 I really do need a command line for it.

Anthony> You
Anthony> check the code out from CVS, or do an apt-get source, you
Anthony> write the code, and you send it to Randolph. It doesn't
Anthony> need discussion here.

I resent the implication that I'm responsible for fixing any problem
that I discover.  I believe there is value in pointing out a problem
report even if you don't have the resources to fix it.

I believe that your proposal will break people who are installing
tasks after initial install.  I believe this is sufficiently common
that we don't want to break this usage pattern.  Either I'm right and
we as a policy group have an obligation to make sure that we implement
the change in a manner that does not break our users--this obligation
existing regardless of whether I'm willing to go off and write code on
this particular issue, or I'm wrong and I'm simply asking for a
feature request.

I'm sorry I don't have a good way to give you evidence on how common the usage 
pattern of installing tasks after initial install is.  I've considered ways of 
getting this info, and the best thing I've found so far is asking users.




>> and to have the policy text say that frontends that handle
>> recommends should handle tasks? =20

Anthony> Not really. Frontends should do whatever their authors
Anthony> deem appropriate and have time to implement. If you want
Anthony> to send in patches, or write your own frontend, more
Anthony> power to you. It's not policy's place to say anything
Anthony> about what features you should and shouldn't implement
Anthony> though.

I disagree in general; there are cases where interoperability requires
us to recommend or even require features be implemented.  However, I
agree that would be going to far.  I believe that by describing parts
of a protocol like the format of the packages file entry you are
implicitly saing that users of that protocol should implement the
parts of that protocol that are appropriate for their application.  I
think a footnote indicating that we are changing from a model where
tasks depend on a lot of stuff to one where they reverse-recommend
means that some users may still expect to be get useful results by
installing a task package.

Re: Tasks policy

[Steve Greenland]

On 08-May-01, 08:55 (CDT), Sam Hartman <[EMAIL PROTECTED]> wrote: 
> >>>>> "Anthony" == Anthony Towns  writes:
> Anthony> Remember: the point of tasks is to make the initial
> Anthony> install simpler, so that people can get started on Debian
> Anthony> without having to wade through dselect.
> 
> Yes, that was the original point of tasks.  However, tasks are also
> used today by people who want to get a set of software installed after
> the initial install. 

If the "set of software" is a task, then they can run tasksel.

If the "set of software" is just a logical grouping of related packages
(emacs, say, or the roxen stuff) then a simple meta package can do the
job. Perhaps part of the tasks policy proposal should be to specify
an alternative mechanism/naming standard for such groupings (and
explain why they are not "tasks". Something like appending "-group"
(e.g. emacs-group, roxen-group), so that one can do "apt-cache search
'-group'" to find all those meta packages.


-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: Tasks policy

[Anthony Towns]

On Tue, May 08, 2001 at 09:55:48AM -0400, Sam Hartman wrote:
> > "Anthony" == Anthony Towns  writes:
> Anthony> Remember: the point of tasks is to make the initial
> Anthony> install simpler, so that people can get started on Debian
> Anthony> without having to wade through dselect.
> Yes, that was the original point of tasks.  However, tasks are also
> used today by people who want to get a set of software installed after
> the initial install.  [...]

> Yet I understand we have finite time.  Would it be reasonable to get
> tasksel install task-name added as a command line invocation for
> people to use in scripts

I'm not sure what scripts have to do with anything, but adding a command
line option is entirely trivial. You check the code out from CVS, or do
an apt-get source, you write the code, and you send it to Randolph. It
doesn't need discussion here.

> and to have the policy text say that
> frontends that handle recommends should handle tasks?  

Not really. Frontends should do whatever their authors deem appropriate
and have time to implement. If you want to send in patches, or write
your own frontend, more power to you. It's not policy's place to say
anything about what features you should and shouldn't implement though.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpQD2ibmsxt0.pgp
Description: PGP signature

Re: Tasks policy

[Sam Hartman]

> "Anthony" == Anthony Towns  writes:


Anthony> On Mon, May 07, 2001 at 07:32:10PM -0400, Sam Hartman
Anthony> wrote:
>> So, I think that support in tools besides tasksel is critical
>> to this policy proposal being useful.  I don't like the idea of
>> having frontend-specific fields being mandated by policy and
>> don'tt see a need for tasksel to be a distinguished frontend.
>> I understand why apt-get might not want to support or
>> reverse-recommends, but I think that the actual frontends
>> should support this.

Anthony> Remember: the point of tasks is to make the initial
Anthony> install simpler, so that people can get started on Debian
Anthony> without having to wade through dselect.

Yes, that was the original point of tasks.  However, tasks are also
used today by people who want to get a set of software installed after
the initial install.  I know many Debian users who expect to be able
to do apt-get install task-blah long after the initial install. While
I was not involved as a developer at the time this discussion happened
the last time, I saw a major advantage of tasks over profiles that I
could install new tasks as I found I needed them rather than having to
reinstall a system and select a new profile.

We will never fully be able to support the users who have grown used
to being able to apt-get install tasks; you have convinced me of that.
However policy's primary purpose seems to be to document existing
practice and I don't think that we are doing that very well by
dropping support for the existing practice of usefully adding tasks
after the initial install.

Yet I understand we have finite time.  Would it be reasonable to get
tasksel install task-name added as a command line invocation for
people to use in scripts and to have the policy text say that
frontends that handle recommends should handle tasks?  I'm not
particularly concerned about the specifics of the text, but I believe
we must allow people an option to continue to use tasks in interactive
scripts and we should encourage people to support it appropriately.

--Sam

Re: Tasks policy

[Julian Gilbey]

On Tue, May 08, 2001 at 02:54:59PM +1000, Anthony Towns wrote:
> Remember: the point of tasks is to make the initial install simpler,
> so that people can get started on Debian without having to wade through
> dselect.
> 
> So it's not a problem if *nothing* other than tasksel can handle
> installing and removing tasks elegantly yet. It's unlikely dpkg or apt-get
> will handle tasks directly ever, but perhaps some of the frontends (deity
> or dselect) will eventually. If you want to hack on this at some point,
> that's fine, but getting tasks to work for their primary goal is much
> more important right now.

Totally agreed and understood!

My thought was simply that it would be easier for people to make sense
of if they could just look at the control file of one package
(task-foo) rather than searching through the control files of all
packages.

But again, you have working code, so the point is somewhat moot.

> Task: headers are more akin to Section: headers than Recommends:. Both in
> that people really ought to be able to just uninstall a package if they
> don't like it, and in that the complexity of dependency specifications
> just isn't warranted. It's quite reasonable, for example, to try
> to setup a mail server (with SMTP and POP and IMAP and maybe even a
> webmail application, say) and then decide you'd like to replace exim
> with postfix, eg.

Sort of agreed, which was why I said that it must have a different set
of rules.  Remember that the Task: header will be under the control of
a strictly limited number of packages.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Tasks policy

[Anthony Towns]

Replying to a few messages at once.

On Mon, May 07, 2001 at 06:16:29PM +0100, Julian Gilbey wrote:
> My thought was that apt and dselect would be taught to recognise
> Tasks: as a new type of dependency header, similar to Depends,
> Recommends and Suggests, but with slightly different rules.

On Mon, May 07, 2001 at 07:32:10PM -0400, Sam Hartman wrote:
> So, I think that support in tools besides tasksel is critical to this
> policy proposal being useful.  I don't like the idea of having
> frontend-specific fields being mandated by policy and don'tt see a
> need for tasksel to be a distinguished frontend.  I understand why
> apt-get might not want to support or reverse-recommends, but I think
> that the actual frontends should support this.

Remember: the point of tasks is to make the initial install simpler,
so that people can get started on Debian without having to wade through
dselect.

So it's not a problem if *nothing* other than tasksel can handle
installing and removing tasks elegantly yet. It's unlikely dpkg or apt-get
will handle tasks directly ever, but perhaps some of the frontends (deity
or dselect) will eventually. If you want to hack on this at some point,
that's fine, but getting tasks to work for their primary goal is much
more important right now.

On Mon, May 07, 2001 at 04:23:47PM -0400, Joey Hess wrote:
> > My thought was that apt and dselect would be taught to recognise
> > Tasks: as a new type of dependency header, similar to Depends,
> > Recommends and Suggests, but with slightly different rules.
> If this were done, I would much prefer it were called Reverse-Recommends,
> since such a thing is useful for other purposes too. 

Task: headers are more akin to Section: headers than Recommends:. Both in
that people really ought to be able to just uninstall a package if they
don't like it, and in that the complexity of dependency specifications
just isn't warranted. It's quite reasonable, for example, to try
to setup a mail server (with SMTP and POP and IMAP and maybe even a
webmail application, say) and then decide you'd like to replace exim
with postfix, eg.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpHR5WaG1cXE.pgp
Description: PGP signature

Re: Tasks policy

[Julian Gilbey]

On Mon, May 07, 2001 at 04:23:47PM -0400, Joey Hess wrote:
> > My thought was that apt and dselect would be taught to recognise
> > Tasks: as a new type of dependency header, similar to Depends,
> > Recommends and Suggests, but with slightly different rules.
> 
> If this were done, I would much prefer it were called Reverse-Recommends,
> since such a thing is useful for other purposes too. I was thinking that
> the relationship created by a Task: field is a reverse dependancy, but
> that is not true, it is not as hard a relation as a dependancy since it
> can be overridden in many ways (the simplest being, get a Packages file
> that does not include the package with the Task: field). Instead, it's
> like a recommends.

Gosh, that's not quite what I meant, but it could be an interesting
idea.  I was still thinking in terms of the task-* packages themselves
containing a Tasks: field in place of Depends and Recommends fields.

> And while we're at it, we could implement Reverse-Suggests too, and
> finally satisfy RMS..

What about "Enhances"?  Or is it not yet up to it?

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Tasks policy

[Sam Hartman]

> "Anthony" == Anthony Towns  writes:

Anthony> --HG+GLK89HZ1zG0kk Content-Type: text/plain;
Anthony> charset=us-ascii Content-Disposition: inline
Anthony> Content-Transfer-Encoding: quoted-printable

Anthony> On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin
Anthony> wrote:
>> err, does this break the use of tasks with apt-get later on?
>> I've found it very useful to do (for example) "apt-get install
>> task-x-window-s=
Anthony> ystem"

Anthony> Possibly. task-x-window-system isn't really the greatest
Anthony> example of a task, though.

So, I think that support in tools besides tasksel is critical to this
policy proposal being useful.  I don't like the idea of having
frontend-specific fields being mandated by policy and don'tt see a
need for tasksel to be a distinguished frontend.  I understand why
apt-get might not want to support or reverse-recommends, but I think
that the actual frontends should support this.

Re: Tasks policy

[Joey Hess]

Julian Gilbey wrote:
> On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote:
> > err, does this break the use of tasks with apt-get later on?  I've
> > found it very useful to do (for example) "apt-get install 
> > task-x-window-system"
> > after getting a machine otherwise working (in particular, that's the
> > easy way to go to xf4 - install 2.2, then point to testing, then
> > apt-get install task-x-window-system which pulls in the right things from
> > testing...) 
> 
> My thought was that apt and dselect would be taught to recognise
> Tasks: as a new type of dependency header, similar to Depends,
> Recommends and Suggests, but with slightly different rules.

If this were done, I would much prefer it were called Reverse-Recommends,
since such a thing is useful for other purposes too. I was thinking that
the relationship created by a Task: field is a reverse dependancy, but
that is not true, it is not as hard a relation as a dependancy since it
can be overridden in many ways (the simplest being, get a Packages file
that does not include the package with the Task: field). Instead, it's
like a recommends.

And while we're at it, we could implement Reverse-Suggests too, and
finally satisfy RMS..

-- 
see shy jo

Re: Tasks policy

[Henrique de Moraes Holschuh]

On Sun, 06 May 2001, Anthony Towns wrote:
> So, here's the deal. We need to get a proper policy for tasks fairly soon.

I agree. The current task-* packages are mostly useless cruft for what they
were supposed to do, i.e. help users during the install.

>   * There should only be a limited number of tasks
This is very, very important. I think about 30 is the maximum number of
tasks we should have.

> If people would like to indicate their willingness to second this, I'd be
> happy to write up a proper patch.
Please do, I think this changes are very necessary and I am willing to
discuss and second a proposal about it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgpfJZHtjeHOH.pgp
Description: PGP signature

Re: Tasks policy

[Julian Gilbey]

On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote:
> err, does this break the use of tasks with apt-get later on?  I've
> found it very useful to do (for example) "apt-get install 
> task-x-window-system"
> after getting a machine otherwise working (in particular, that's the
> easy way to go to xf4 - install 2.2, then point to testing, then
> apt-get install task-x-window-system which pulls in the right things from
> testing...) 

My thought was that apt and dselect would be taught to recognise
Tasks: as a new type of dependency header, similar to Depends,
Recommends and Suggests, but with slightly different rules.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Tasks policy

[Anthony Towns]

On Mon, May 07, 2001 at 11:42:49AM -0400, Mark Eichin wrote:
> err, does this break the use of tasks with apt-get later on?  I've
> found it very useful to do (for example) "apt-get install 
> task-x-window-system"

Possibly. task-x-window-system isn't really the greatest example of a task,
though.

You can always run tasksel, select the task, and go "Ok", instead of using
"apt-get install ..." though. Making "tasksel install server-dns" just go
ahead and install the task, bypassing the UI, would be fairly simple too.

> Does it not also make it a lot harder to update and experiment with tasks?

Not really: the Task: headers will be done via overrides, probably sourced
from boot-floppies CVS.

> (Couldn't this also be handled by dropping non-critical task deps to
> "recommends" or something like that, and an apt-get option to "try to
> get the recommends too"?)

In theory it could. In practice, it suffers from recommends being more
appropriately handled in a frontend rather than a lowlevel tool like
apt-get (to paraphrase, barely, Jason's take on apt-get supporting
recommends), and also from the same problems using depends: does: if I
remove a package from the task, the whole task breaks, rather than just
politely including one less package.

This was discussed in a fair degree of depth shortly after potato was
released, btw. Have a look at the thread on -devel which included:
http://lists.debian.org/debian-devel-0008/msg00706.html

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpMAYJLK98Ul.pgp
Description: PGP signature

Re: Tasks policy

[Mark Eichin]

err, does this break the use of tasks with apt-get later on?  I've
found it very useful to do (for example) "apt-get install task-x-window-system"
after getting a machine otherwise working (in particular, that's the
easy way to go to xf4 - install 2.2, then point to testing, then
apt-get install task-x-window-system which pulls in the right things from
testing...) 

Does it not also make it a lot harder to update and experiment with tasks?

(Couldn't this also be handled by dropping non-critical task deps to
"recommends" or something like that, and an apt-get option to "try to
get the recommends too"?)

Re: Tasks policy

[Julian Gilbey]

On Mon, May 07, 2001 at 08:23:52PM +1000, Anthony Towns wrote:
> > Would it not be much easier for the task packages _themselves_ to
> > contain Task: fields, instead of the individual packages, which would
> > function like weak Recommends: fields: 
> 
> Not really. The code's already written to do things the other way around,
> and the main point of "Task:" fields being in the package is so that
> packages can be removed from the archive without breaking any tasks they
> might be a part of.

Oh, yeah, the idea was that if a package doesn't exist, nothing
complains.

> > In this way, the dependency information remains in the
> > domain of the task-* package maintainers, but has the desired
> > function.
> 
> It'd be possible to do this, too (either informally by saying "only
> task package maintainers should mess with this part of CVS" or by making
> dak/dinstall look at the actual contents of the latest task- packages).
> I suspect using CVS'll be easier and at least as good though.

Fair enough; you have the code.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Tasks policy

[Anthony Towns]

On Mon, May 07, 2001 at 11:06:41AM +0100, Julian Gilbey wrote:
> On Sun, May 06, 2001 at 04:42:19PM +1000, Anthony Towns wrote:
> > (Cc'ed to debian-boot)
> > tasksel in sid supports a "Task:" header for packages so we can be a
> > little more flexible than having every task- depend on everythig in it.
> Can I make a suggestion?  This sounds really good in general, but the
> one headache you've identified is the necessity to set up the Task
> fields in lots of packages and the consequent maintenance of this data.

I'm thinking it'll probably be best if a list of which packages are
in which tasks is maintained as part of boot-floppies CVS, and that
dak/dinstall updates the Task: fields based on that.

> Would it not be much easier for the task packages _themselves_ to
> contain Task: fields, instead of the individual packages, which would
> function like weak Recommends: fields: 

Not really. The code's already written to do things the other way around,
and the main point of "Task:" fields being in the package is so that
packages can be removed from the archive without breaking any tasks they
might be a part of.

> In this way, the dependency information remains in the
> domain of the task-* package maintainers, but has the desired
> function.

It'd be possible to do this, too (either informally by saying "only
task package maintainers should mess with this part of CVS" or by making
dak/dinstall look at the actual contents of the latest task- packages).
I suspect using CVS'll be easier and at least as good though.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpVfeNHCReI9.pgp
Description: PGP signature

Re: Tasks policy

[Julian Gilbey]

On Sun, May 06, 2001 at 04:42:19PM +1000, Anthony Towns wrote:
> (Cc'ed to debian-boot)
> 
> (First in porbably a series of policy changes needed for woody...)
> 
> So, here's the deal. We need to get a proper policy for tasks fairly soon.
> 
> tasksel in sid supports a "Task:" header for packages so we can be a
> little more flexible than having every task- depend on everythig in it.

Can I make a suggestion?  This sounds really good in general, but the
one headache you've identified is the necessity to set up the Task
fields in lots of packages and the consequent maintenance of this data.

Would it not be much easier for the task packages _themselves_ to
contain Task: fields, instead of the individual packages, which would
function like weak Recommends: fields: they select the packages for
installation if present when first installed, but don't try
reselecting them if they are unselected or later uninstalled.  (Maybe
there could be some sort of "reinstall" facility, though, in
apt/dselect.)  In this way, the dependency information remains in the
domain of the task-* package maintainers, but has the desired
function.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Tasks policy

[Anthony Towns]

(Cc'ed to debian-boot)

(First in porbably a series of policy changes needed for woody...)

So, here's the deal. We need to get a proper policy for tasks fairly soon.

tasksel in sid supports a "Task:" header for packages so we can be a
little more flexible than having every task- depend on everythig in it.
This was discussed on -devel just after potato released, I think consensus
was that we should use override files to populate these fields, rather
than letting maintainers add their own packages directly to tasks. I'm
not sure if we came to a consensus about how these override files would
be maintained though (or who by: ftpmaster? -boot? the individual task-*
maintainers?). It's probably best to put it in boot-floppies CVS, and have
dinstall use that.

The basic way tasks should work are (and I think there's a rough consensus
on this too):

* There should only be a limited number of tasks

* Each task should be useful to a large number of users (special
  interests can use apt-get after install)

* Tasks should be oriented on the goal; two tasks shouldn't do
  effectively the same thing

* Most packages in a task should be specified using the Task: header
  so that (a) they can be removed without necessarily deselecting
  the task, and (b) so that if they get removed before release, the
  task- package doesn't get broken

* task-* packages shouldn't suggest: or recommend: other packages,
  nor depend on virtual packages or list alternative dependencies
  (ie Depends: foo|bar|baz): dependency resolution isn't handled by
  tasksel, and shouldn't be, so a non task-* meta package should be
  used instead if such things are desirable. (Using the Task: field
  probably obsoleted most of the use of recommends/depends in tasks)

* task-* packages shouldn't conflict with each other, or with
  required, important or standard packages (since such things
  can't be resolved from within tasksel). If that sort of thing
  is desired, a metapackage should be used.

* tasks should be priority optional (and thus packages in
  tasks should be priority optional),

Some further things which are probably desirable:

* tasks shoudl have a section of their own
  in dselect. "Section: dummy" or "Section: task" would seem
  sensible to me

* tasks should follow a naming convention so they can be organised
  better by tasksel. Probably:
task-devel-{c,c++,objc,haskell,...}
task-lang-{german,french,japanese,chinese,...}
task-server-{web,news,mail,database,dns,...}
task-user-{desktop,office,games,junior,...}
task-hware-{dialup,printer,laptop,...}

* we should have tasks specifically for emacs and tetex (even though
  both could be replaced by a wordprocessor in task-office, say).
  possibly:
task-sware-{tetex,emacs}
  and require any additional tasks like this get run through policy
  first. If nothing else, historical reasons are a good argument
  for tetex and emacs, and are obviously immune to slipper
  slopes. :)

Note that this requires pretty thorough changes to our task- packages before
release. I think that's entirely desirable though, personally.

If people would like to indicate their willingness to second this, I'd be
happy to write up a proper patch.

If people want to disagree, I'd appreciate it if they'd be willing to put
in the effort to write a better proposal.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgp4xWMmjhKOs.pgp
Description: PGP signature