* Joey Hess [EMAIL PROTECTED] [001206 21:30]:
Task packages are packages whose names are prefixed with `task-'.
Typically they are empty metapackages that merely depend on a collection
of other packages.
Joey, nice work; I agree with the general gist of what you are aiming
for. When I
Another thing that I think is important is that a task should actually
have the effect of installing a multitude of packages. If it doesn't,
you gain nothing over selecting packages by hand.
On Wed, Dec 06, 2000 at 09:28:23PM -0800, Joey Hess wrote:
The resulting list would look something like:
Processing commands for [EMAIL PROTECTED]:
reassign 34672 debian-policy
Bug#34672: Installing xlib6g removed xlib6.
Bug reassigned from package `xlibs' to `debian-policy'.
severity 34672 wishlist
Bug#34672: Installing xlib6g removed xlib6.
Severity set to `wishlist'.
8---
Joey Hess wrote:
I suspect most people don't look at tasksel on a regular basis, but if
it were possible to do a fresh woody install today, here is what you
would see:
An excellent summarisation, Joey: there is a problem here.
Your suggestion is one way of looking at it, but is it the right
Something like:
Internet
-Browsers
--lynx (default)
--Mozilla (which would select K or gnome or whatever the default is)
--...
-MUAs
--mailx (default)
--mutt
--...
-IRC Clients
--BX (default)
--IRCII
--...
-...
Programming Environment
-C (default)
-C++
-Fortran
-Python
-...
Servers
-Database
On Wed, Dec 06, 2000 at 02:29:18PM -0800, Brian Frederick Kimball wrote:
At 10:31 pm -0800 on December 04, 2000, Chris Waters wrote:
We *do* distribute the GPL with the binaries. It's in the source
tarball.
Don't you see anything wrong with this statement?
sigh What part of we distribute
In message [EMAIL PROTECTED], Ben Collins writes:
Which doesn't include some very important tasks (task-web-server
and task-programming come to mind), but is a large improvment from
what we have now. And almost even fits on one screen.
Maybe we need a way to define subtasks so we get
On Thu, Dec 07, 2000 at 12:45:13AM -0500, Ben Collins wrote:
Which doesn't include some very important tasks (task-web-server
and task-programming come to mind), but is a large improvment from
what we have now. And almost even fits on one screen.
Maybe we need a way to define
On Thu, Dec 07, 2000 at 12:40:27AM -0500, Branden Robinson wrote:
Sounds good to me except that I think distinct, integrated desktop
environments comprising many packages should each be able to have tasks.
This means I think there should be a task-gnome equivalent to task-kde.
(AFAIK, the XFCE
On Wed, 6 Dec 2000, Seth Arnold wrote:
* Joey Hess [EMAIL PROTECTED] [001206 21:30]:
Task packages are packages whose names are prefixed with `task-'.
Typically they are empty metapackages that merely depend on a collection
of other packages.
Joey, nice work; I agree with the
Seth Arnold wrote:
Joey, nice work; I agree with the general gist of what you are aiming
for. When I saw the list, I thought to myself, ``this doesn't buy much
over selecting the packages by hand''.
Exactly.
However, I think we can agree that many of these packages are *useful*,
even if
Cheng H. Lee wrote:
I agree that it is a bit long; however, I think the best way to resolve this
would be to tell the user that there are more tasks listed below
people_who_have_never_run_tasksel_lately_if_at_all++;
Some of these tasks should be folded into one, e.g. the multiple KDE or
Ben Collins wrote:
Maybe we need a way to define subtasks so we get output like:
[ ] LDAP : LDAP libraries, server and clients
[ ] LDAP Devel : LDAP Development libraries
[ ] LDAP Server : LDAP Server
[ ] LDAP Tools : LDAP
Branden Robinson wrote:
The singular of criteria is criterion.
I can't belive youy started out like that ...
Sounds good to me except that I think distinct, integrated desktop
environments comprising many packages should each be able to have tasks.
This means I think there should be a
Aaron Lehmann wrote:
Another thing that I think is important is that a task should actually
have the effect of installing a multitude of packages. If it doesn't,
you gain nothing over selecting packages by hand.
No, you gain the ability to say I want to do foo, and get everything you
could
Rando Christensen wrote:
Instead of the task-* packages, there really should just be a preselected
set of packages that people can use. A few of them, much like you would
expect in other distributions.
AFAIK, that's what the base system and standard are.
even if it itself USED the task-*
Andrew McMillan wrote:
Your suggestion is one way of looking at it, but is it the right way?
I seem to never install using tasks because they are too general - they
make decisions the way I wouldn't - and they are (at the same time!) too
specific - they frequently make decisions I can make
Joey Hess [EMAIL PROTECTED] writes:
I would furthermore suggest that localization tasks have some extra
structure placed upon their names: e.g., task-language-zh,
task-language-ja, etc.
I have some other ideas about those, they can just be automatically
selected based on the
At 12:46 am -0800 on December 07, 2000, Chris Waters wrote:
On Wed, Dec 06, 2000 at 02:29:18PM -0800, Brian Frederick Kimball wrote:
At 10:31 pm -0800 on December 04, 2000, Chris Waters wrote:
We *do* distribute the GPL with the binaries. It's in the source
tarball.
Don't you see
I'm going to chime in with my non-DD-ness. ATM the people who decide a
task package are not the ones who will ever use them. Tasks were by
definition not for developers, but for FNGs--DD's should know what they
want. Has anyone gone to -user and ASKED? I would submit that the first
step in
On Thu, Dec 07, 2000 at 10:39:34AM -0800, Joey Hess wrote:
Well fine. This is why I want to come up with a set of guidelines and
put them in policy, then we can apply them to individual cases.
Yes, and as I suggested the last time a similar discussion arose,
perhaps the first step might be to
At 03:29 pm -0700 on December 07, 2000, John Galt wrote:
DANGER WILL ROBINSON! If a task-* package only installs one package, it
sounds like the package description isn't being clear enough in the
package to be installed.
A clear description is useless to a user that doesn't have the time
Package: debian-policy
Version: 3.2.1.0
Severity: wishlist
We should have a c++-compiler virtual package to match the c-compiler
package. At present, at least in potato, only g++ Provides this
virtual package, but there may be others. And policy should encode
current practice.
Julian
--
Chris Waters wrote:
Yes, and as I suggested the last time a similar discussion arose,
perhaps the first step might be to come up with an alternative naming
scheme for empty packages which exist to make it easier for the user
to install a set of packages, but which are NOT designed to appear as
On Thu, Dec 07, 2000 at 03:24:42PM -0800, Joey Hess wrote:
Chris Waters wrote:
Yes, and as I suggested the last time a similar discussion arose,
perhaps the first step might be to come up with an alternative naming
scheme for empty packages which exist to make it easier for the user
to
On Thu, Dec 07, 2000 at 12:45:13AM -0500, Ben Collins wrote:
Which doesn't include some very important tasks (task-web-server
and task-programming come to mind), but is a large improvment from
what we have now. And almost even fits on one screen.
Maybe we need a way to define
On Thu, Dec 07, 2000 at 10:37:16AM -0800, Joey Hess wrote:
Well, I think we should have a task-desktop that includes either one,
or, if we really cannot make up our minds, _both_.
Or, if we get enough clue, _neither_ and a nice simple X setup that a
new user will soon get acustomed to.
Again, how about the target audience for a task-*: -user? If it's for Joe
Newbie, wouldn't it be good to get his input before carving something in
stone?
On Thu, 7 Dec 2000, Chris Waters wrote:
schnip
A requirement for discussion on -policy before adding a task package
might well go a
John Galt [EMAIL PROTECTED] writes:
First of all, what newbie is going to want to run a mailserver? Running a
mailserver is usually a job for a medium-level sysadmin: certainly not
a job to add for someone trying to get comfortable with a system. Where's
the equivalent task-POP?
Um, no.
Some time ago, I think there was a proposal to change the way task
packages are put together. Instead of task-* packages, relevant packages
would have something like:
Task: programming/c
If people want the kind of flexibility described in the thread (trees,
subtrees, etc). We should look into
* John Galt [EMAIL PROTECTED] [001207 18:14]:
distributions is the right one. Uncle Debian in his wisdom makes the
choice for him and takes care of the details.
Fuck Uncle Debian and the horse he rode in on if that's the case.
Now John, I consider myself fairly competent; however, with
On Thu, Dec 07, 2000 at 08:16:49PM -0800, Seth Arnold wrote:
Now John, I consider myself fairly competent; however, with three dhcp
clients to choose from (an actual situation from many months ago) many
folks won't know which one is *best*, as defined by ``works on the
kernel as shipped''. How
32 matches
Mail list logo
