On Sat, 16 Dec 2000, Britton wrote:
>
> > Currently we've only had two real excuses for using empty packages:
> > for handling splits, and for tasks. It seems a little like people want a
> > third sort, just as a collection of related packages that you generally
> > want to install at once. Thi
> Currently we've only had two real excuses for using empty packages:
> for handling splits, and for tasks. It seems a little like people want a
> third sort, just as a collection of related packages that you generally
> want to install at once. This might be just an artifact of "recommends"
> not
On Thu, Dec 07, 2000 at 05:21:09PM -0800, Joey Hess wrote:
> Fast forward 8 months to the present, and I'm seeing a huge number of
> people who don't have the slightest clue about task packages. Did they
> forget so soon? Did they not pay attention last winter? I don't know..
Well, existing practi
On Sun, Dec 10, 2000 at 03:49:13PM +0100, Wichert Akkerman wrote:
> Previously 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
Previously 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
Joey Hess <[EMAIL PROTECTED]> writes:
>So how's this:
>
> Task Packages
> -
>
> Any package whose name begins with `task-' is known as a "task
> package". Task packages are intended to help a new user install a set of
> packages which they need to perform a specific task. Since a
I think what you are proposing is too much granularity to be worth the
effort, if that much control is needed, it will be easier to just use
dselect anyway. Remember tasks are geared towards new users installing
for the first time. We don't want them to ultimately need to look at a
task package
> "Dirk" == Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
Dirk> Interesting timimg :)
I've noticed it too. I just got back on list, had ideas, and after
reading farther, found other threads about similar topics. Neat.
It's good to be back on debian-devel... that's iff I can keep up w
Interesting timimg :)
I finally got a go-ahead from the previous task-science maintainer to adopt
his package, which I found muddled (and buggy where it intersected with some
of my packages). I posted a suggestion for a new one to d-devel last night,
and so far only heard "break it up further i
On Thu, 7 Dec 2000, John Galt wrote:
> First of all, what newbie is going to want to run a mailserver?
I don't know. And neither do you. Stranger things have happened. Should
they wish to install a mail server, Debian is making things a little
easier for them.
Running a
> mailserver is usual
On Fri, 8 Dec 2000, David Schleef wrote:
> 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
On Thu, 7 Dec 2000, 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.
>
> even if it itself USED the task-* things, that's too much
On Fri, Dec 08, 2000 at 01:46:11PM -0800, David Schleef wrote:
> > *THIS* is where the task- system will help new users -- competent or
> > not. It allows Debian to help people choose, when they don't know what
> > is best -- not when they are too stupid to know what is best.
>
> If this is really
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''.
On 08-Dec-00, 02:29 (CST), Britton <[EMAIL PROTECTED]> wrote:
>
> Also, why should the user ever see a task like
> devel-common, shouldn't this be essentially depended on by all the dev
> tasks? And Debug should be pulled in for any languages for which it
> includes debugging tools.
No, that'
This sounds good to me. Also, why should the user ever see a task like
devel-common, shouldn't this be essentially depended on by all the dev
tasks? And Debug should be pulled in for any languages for which it
includes debugging tools. In at lease some cases (SGML at least) it would
seem to me
[ I'm dropping the -devel cc in the hope of having a useful discussion
instead of 10 non-useful offtopic discussions. Blah. ]
Chris Waters wrote:
> Ok, here's a slightly better proposal: why not simply handle the task-
> package namespace the same way we do virtual packages and menu
> entries.
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''.
* 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, wit
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 imp
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, n
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:
>
> A requirement for discussion on -policy before adding a task package
> might well go a long wa
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.
On Thu, 7 Dec 2000, Jaldhar H. Vyas wrote:
> On Thu, 7 Dec 2000, John Galt wrote:
>
> > On Thu, 7 Dec 2000, Joey Hess wrote:
> >
> > > 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.
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 defin
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
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
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
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
On Thu, 7 Dec 2000, John Galt wrote:
> On Thu, 7 Dec 2000, Joey Hess wrote:
>
> > 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 pack
On Thu, 7 Dec 2000, Joey Hess wrote:
> 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 sa
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 ref
>> 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
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 ma
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-*
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
coul
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
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 : LDA
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 GN
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
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 wit
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 X
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
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
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
--Pos
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 "r
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:
* 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
On Wed, Dec 06, 2000 at 09:28:23PM -0800, Joey Hess 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.
What is task-programming supposed to include
>
> 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 output like:
[ ] LDAP :
On Wed, Dec 06, 2000 at 09:28:23PM -0800, Joey Hess wrote:
> 1. It is long. More than 2x as long as the list in potato, much longer than
>one or even two screens. It is approaching a length that most hurried
>people will probably not bother reading. I'll bet that back in the early
>d
On Wed, Dec 06, 2000 at 09:28:23PM -0800, Joey Hess wrote:
> We need to trim this list down, and I propose an objective criteria
> that can go into policy, as follows:
The singular of "criteria" is "criterion".
> %<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<
>
> 2.3.
52 matches
Mail list logo
