Re: cleaning up our task packages
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. 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 ever want to do foo. If that only involves one or two packages, no
> > > problem.
> >
> > 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.
>
> Fwiw although task-imap only installs one package, the package it installs
> pulls in another couple of packages. Does that count?
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?
> I invite any improvements to the description of uw-imapd but I think it's
> pretty good as is.
In fact, it's more newbie oriented than task-imap. There were two
possibilities allowed for a single package task, you took the wrong one
and took offense. I guess this is to cover the fact that the
true reasoning behind task-imap is offensive to the user, as you prove
later.
> > I would submit that the only useful task-*
> > package is one that installs 2+ packages--a task-* package that installs
> > only one package is a pretty good indicator of brokenness either in the
> > installed package or the suitability of the task (the one other thing it
> > may indicate is a transitive lack of packages to install--basically the
> > task got built before the packages implict got built, which is a
> > brokenness in and of itself, but one that will fix itself).
> >
>
> I think you're missing the point. Let's assume Joe Newbie wants to
> install an IMAP server. Tasksel gives him the ability to do just that
See above: if he's really a newbie, whatinhell is he doing running an
IMAP server in the first place?
> without wading thorugh the 5000-long list of packages. It saves him
This sounds like a problem of dselect, not an added function of tasksel.
> having to think about which of the three or more IMAP servers in the
THE >>>HELL<<< YOU'RE GOING TO USE TASKSEL TO REMOVE THE SYSADMIN'S
"BURDEN" OF CHOOSING SYSTEM POLICY!!!!! I will fight you on this one
unitl hell freezes over. The System Administrator is assumed competent to
make their own decisions on their system, and NO DD has the right to
override it or assume otherwise. Relieving the Sysadmin of "having to
think" is assuming the sysadmin is stupid, and implying that YOU are the
stupid one.
> 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.
> As Joey has already said, most of us will find that kind of automatic
> choice too.restrictive. Fine, task packages aren't meant for us.
The thing is that you've gained no extra functionality by allowing the
restriction of choice: you still have to choose as many packages after
tasksel as before--you just now have a more limited selection "for the
syadamin's own good", and that's not an acceptable reason. Multiple
package tasks at least give the sysadmin a minor break in individually
selecting packages, so have a modicum of added functionality to offer.
--
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email galt@inconnu.isu.edu
Reply to: