Re: Priorities
Sorry, I'm not on debian-policy, but since I was one of the ones who
lobbied for task packages, just a few random thoughts.
Anthony Towns <aj@azure.humbug.org.au> writes:
> I don't really understand task packages. I'd assume that they're there
> to make it easy for people to do some particular common tasks (setup a
> desktop environment, interact with your computer in japanese, play music,
> do 3d graphics, program).
The main purpose is to obviate the reason to run dselect on initial
install, picking thru > 4,000 packages or whatever.
A side bonus is that if we can maintain the task package, allowing
packages to pull in new pkgs as they are available.
A major downside to task packages is that they rely on depends, and if
you remove one item, the whole task gets taken out. But, I consider
that an acceptable compromise.
> It seems to me like it might be bing abused somewhat as an excuse to
> advertise particular groups of packages. task-webserver-roxen, and
> task-x-window-system come to mind as being more an excuse to group a
> bunch of packages together than really focussing on being something
> useful for the prospective user, for example. OTOH, "I want a useful X
> environment" isn't an unreasonable task.
I don't think it is. But I do applaud the idea to focus the tasks of
a task package on what the user wants to do, rather than on a specific
technical set.
> Actually, going a bit further on that idea.
>
> The *task* is really "usable 2d windowing environment for accessing
> programs", it's not kde, or gnome, or xlib, or motif. Is it really
> sensible to have the choice between the various windowing toolkits
> made here? Would it be better/possible to have a task-desktop that
> included both gnome and kde, and the best apps from both, and just let
> the user use them? Obviously the packager would have to make a choice
> amongst xdm, gdm and kdm, but that doesn't seem unreasonably difficult.
I agree.
Sure, the tasks-* packages are going to pull in a lot of bloat, but
remember they are targetted at newbies rather than the experts, who
don't really need their hand held anyhow.
> I don't see a point to:
>
> python
> - how do I know whether I'm going to write "complicated" apps or not?
I don't know that I completely agree. I see your point, but then
again, "I wanna program in python" seems to me to be a reasonable
desire for a user to have.
> gnome-games
> - i just want to play games, i don't care what toolkit they use
Agreed. Should not be a task, I think.
> tcltk
> - how do i kow if i want to run tcltk programs? debian packages will
> install it if they need it, presumably the lsb will do likewise,
> and anything i buy will tell me what i need to install, surely?
Yup.
> debug
[...]
> devel-common
[...]
Agreed.
> doc
> - eh?? i have to go out of my way to get "General documentation"??
Isn't there a 'task-newbie-doc' ?
This package is way to general to be helpful. Would a user just say,
"I wanna read documentation" ?
> python-web
> - a general "i want to work on interactive web sites" task would make
> sense to me (one that included, presumably, a free java, and zope,
> and tomcat, and tools to do cgi in perl and python and whatever else)
> but just for pythn? "apt-get install zope" if that's what you want.
Agreed.
> The following seem to be just random collections of packages:
>
> python-bundle
> x-window-system
> gnome-apps
> gnome-net
I agree with all of these aside from 'x-window-system'. I think "I
wanna have the X11 Window System on my machine" as a reasonable
desire. Although I'm haven't looked in depth at the difference
between this and the x-window-system-core package.
> Less clear to me are:
>
> sgml-dev
> - what does it mean to be an SGML "developer" rather than an
> author? making up new SGML dtd? writing programs that interpret
> SGML? Is this really that separate from task-sgml?
Yes. There are document authors (who want sgml) and document
engineers (who want sgml-dev). The latter are the ones who (a) write
the code to process/format SGML in customized way (b) write code which
produces SGML/XML, (c) write code which has to parse or deal with
SGML/XML data.
> gnome-desktop
> x-window-system-core
> - a task-desktop would make more sense to me here
Yup.
> We could have some extra tasks:
>
> * authoring HTML pages (somewhat different to web development
> in the python-web sense)
'task-sgml' kinda takes are of this.
> * browsing the web (without having to download plugins all the
> time, having java support, etc)
Well, we do have virtual packages for this.
> * writing Word documents? word processing in general? (cf the
> tex and sgml tasks)
Perhaps -- 'task-productivity' ? Could pull in stuff like star
office, gnumeric, etc.
> * spreadsheets? databases (the GUI side, not the SQL
> side)? office apps (appointments, contacts, time monitoring)?
Falls into productivity -- aside from the databases task. See, I
think you are taking it a bit too far with 'task-database'. I don't
think it's so reasonable (although we're getting subjective) for a
user to ask 'I wanna run a database' -- my question to them would be
"which database".
The task-* packages are meant for pulling in a lot of pakcages,
whereas the virtual packages present alternatives, such as, to the
question "I want a free SQL server". We might wanna pack both of
these meanings into task packages but I don't think that necessarily a
good idea.
> * project management (revision control, design, bug tracking; this
> may be what the -devel-common task is intended for, it might
> be nice to rename it if so)
Well, don't confuse developers with project managers. Project
managers are generally tracking budgets and such.
> * strange languages (prolog, lisp, mercury, scheme, intercal...)
Why would this be a task?
> * perl-dev? php-dev?
Perhaps.
> * setting up an LDAP-controlled network (install a server task on
> one or more machines, and clients on all the others, answer
> the debconf questions and you've got yourself a easily admined
> multi-user network where people can login on various systems,
> share their home directories, and what not
>
> * web-server? irc-server? firewall?
Debatable, I think. We're moving away from the target audience of
newbie users. Maybe it would be useful, but I'm not sure. I think
you're kinda asking to extend the task-* packages to also include
debconf config scripts for setting up servers? Is that the best way
to do it? I would think the openldap package itself, for instance,
should handle it's configuration.
> * setting up a local printer? ("my computer has a modem/is a laptop",
> vs "my computer has a printer"?)
Yes, this would be a great package. But I woudl jsut include lprng,
cups, magicfilter, or whatever is the nice tools for printing, and not
bother with the hand-holding/config side.
> * dialup-cable-modem? dialup-adsl?
I didn't realize you could dialup cable and adsl. Again, we're mixing
pkg collections with system configuration. Not a good idea, IMHO.
Mostly I say that because I think that system configuration is not a
debian-specific thing and using task-* packages will prevent any
interaction with non-Debian hackers.
> So all of this indicates to me that:
>
> a) There are a bunch of task- packages that aren't really useful.
I agree.
> b) We can probably split tasks into three areas:
>
> * Install enough packages to satisfy most people who might
> say "I want to do <..> with my computer"
Yes.
> * Help someone set up some complicated service
I disagree with this use. It should be done either as part of the
upstream packages in question or in other ways that allow interaction
with non-Debian open source hackers. Let's not fall into "not
invented here" syndrome.
> * Help someone make use of some hardware they have attached
> to their computer, in a fairly generic way.
Again, disagree.
> I don't see any *good* reason for task- packages to conflict, though,
> in the above, most task packages should be completely independent.
Yup.
> So, going back to what I've said previously (which is probably
> completely out of the blue for -boot folks, but what the hey), I think
> it's reasonable to expect the -task packages and everything they depend
> on to be standard (or above optional, anyway), and to satisfy all the
> policy and so forth that goes with that.
Sounds fine with me.
BTW, I suggest you file WNPP requests for the nice tasks you thought
of that don't yet exist.
It's very good that somone is thinking about this now rather than just
complaining about it when it's too late (i.e., freeze) to do anything.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: