On Sun, Jan 02, 2000 at 09:55:58AM -0800, Robert Woodcock wrote:
> > First, how do the various tasks packages affect this? Do they include
> > all of standard plus some other stuff, or would, eg, a `router' task
> > completely obviate the "But I don't want it on my router" complaints?
> They don't. Tasks can have any list of packages they want, independent
> of priorities. Most include all of standard.
Okay, so for most people this doesn't matter in the slightest. Since most
people, and especially newbies, and even the ones spending 50 hours to
download their system over a 2400 bps modem, will have a specific task
installed, and not worry at all about what's in standard and what's not.
> > And if this is the case, what relevance does standard have at all?
> AFAIK it only affects dselect, although I'd expect some of the dselect
> replacements (capt, gnome-apt) to make this distinction as well. (Does
> anyone know if they do?)
>
> When dselect encounters a new package (the first time it runs everything is
> new), if it is of priority 'standard' or higher, it is automatically
> selected for installation.
Is this even after you've selected a task? If so, I'd consider this a
bug in the tasks mechanism. If not, this is largely irrelevant, and as
far as packages that are actually new go, doesn't apply to emacs and
tetex since they've been there for eons anyway.
> > Second, are non-experts expected to be able to remove standard packages?
> Depends on the non-expert. :)
> I'd expect that a non-expert able to type 'dselect' at a command line [1]
> would be able to remove a standard package without trouble.
Ditto apt-get remove, and ditto, one presume, any of the various apt
frontends if and when they become usable.
> > Thirdly, what, exactly, is the point of `Standard'?
> If you bypass the task package selection screen (answer "n" when it asks
> you), it's what you get (unless you bypass dselect as well).
Which, one presumes, you'd only do if you Knew What You Were Doing, and
wanted to select packages yourself.
> It also affects upgrades. Say a new package was introduced into woody.
Which isn't relevant for emacs or tetex.
> > Personally, I would
> > have thought making it a fairly complete `This is more than enough to get
> > you started, and should have most of the things you've probably heard
> > that Unix has' would be the most reasonable definition [0]. It seems to me
> > that making it `The minimum stuff for a usable system' would just be
> > repeating the `required' priority, and `Stuff everyone wants' is likely
> > to be impossible to actually make.
>
> > I guess this is basically, why is bloat more important than functionality?
>
> I'm reading that question as "why is a lack of bloat more important than
> functionality?". Please correct me if I'm wrong.
>
> It's the degree of bloat vs. the degree of functionality that concerns me.
So what you're basically saying is, `standard is everything you'd expect
on a unix system, except emacs and tex and x11 because they're bloated
pieces of rubbish'. (As opposed to the current one which is more along
the lines of `standard is everything you'd expect on a unix system,
including emacs and tex, even though they're bloated pieces of rubbish,
but definitely not x11, because windows systems are for pansies'. I'd
much rather just go with `everything you'd expect on a traditional unix
system' or similar)
I don't see any reason to focus on this at all. Sure, they're a pain to
download over modem. That's why G*d invented CDs and the hold option in
dselect. Sure, we could cut down the size of standard by half, while only
cutting the functionality by, say, 1/8th or so. Great. So what? If you
want a small system, you can get it by starting from base and working your
way up. And that's better because it's absolutely minimal, it doesn't
include any cruft like dpkg-perl, or gcc. And in the meantime, we've made
standard nothing more than an arbitrary collection of packages, defined
by something as nebulous as `packages that might be useful, but that no one
could be bothered complaining about', or similar.
> It's also the installation time. One of the motives for bypassing the task
> selection screen is to save time.
Huh? Why would this /save/ time? I mean, (a) if you do this, you'll get
emacs and tetex, which, as you say will take a while, and (b) if you
do this, you'll probably spend hours sifting through dselect to see if
anything interesting catches your eye. Or, at least, that's what happens
to me.
> > All I can see here is a closed-minded `I don't want LaTeX or Emacs, and
> > I don't even want to have to think about it to avoid them'. :-/
> Because this isn't an issue of right or wrong, only what is preferred for a
> majority, there is no such thing as a logical response to this sentence.
Except that, afiact, we've already established that what's in standard
doesn't affect the majority at all. And of those it does affect, you've
made one bunch of people type a little less, and another bunch of people
type a little more. And maybe you've made a couple of people who couldn't
even be bothered noticing that three packages are taking up most of their
download time have smaller phone bills.
I mean, the people you're going to affect here are:
* people with slow connections, no CD ROM drive, and/or very
limited disk space
* ... who also specifically don't use the task sets
* ... and who care about their download time but can't be
bothered even looking at the 100 odd packages that make up
Standard/Important/Required to see if there are any they
don't need.
That is, a minority of a minority of a minority. I don't see the point.
> > I also have to wonder at the utility of moving things *to* optional, which
> > is already getting fairly cumbersome.
> Optional has no significance with any tool, so having it encumbered with
> lots of packages shouldn't be a concern.
Except when you're looking through it for things you want to install.
Intriguingly, none of the task-foo packages in my available file seem to
depend/recommend or even suggest emacs. A couple depend on xemacs though,
namely sgml and japanese. TeX is a task all of its own.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpzUlb7CsQmX.pgp
Description: PGP signature