Date:        Fri, 31 Dec 2004 18:38:51 -0500 (EST)
    From:        Todd Vierling <tv@duh.org>
    Message-ID:  <Pine.NEB.4.61.0412311837090.13628@server.duh.org>

  | "make packages faster to install" is something like it;

I assume you mean elapsed time (admin effort perhaps) rather than cpu
time, as nothing we're discussing really impacts on the latter.

In that case, you cannot really want to require people to have to
manually edit a config file to enable things - so, you'd probably
agree that having a command that enables (and starts - perhaps controlled=

by an option) packages after they're installed would be the right
approach, right?   That makes it even easier, and ...

  | "make packages with
  | daemons easier to enable for automatic startup without surprising the=
 admin
  | by starting up unexpectedly" is probably closer.

still makes it a two step process.

And if we were to have this two step process, then it doesn't really
make any difference whether copying the rc.d file is in step 1 or step 2,=

does it?

  | (Although this should have been inferrable directly from the steps I =
already
  | described.)

No, attempting to determine someone's objectives from their actions is
too hard to even contemplate.

jmmv@menta.net said:
  | Add: "the packaging system is who manages files and keeps track of th=
em". =


Once again, this is a processing step, not an objective.

But even then, it is useless as an requirement as it is anyway.   I have =
to
assume it means "the packaging system is who manages files it installs...=
"
and not "all files related to the package", or you'd be demanding that a
web server package (apache, ...) manage all of a site's web pages, and
that's obviuusly not reasonable.

So, this ends up begging the question - you want the package system to
manage the installed rc.d script, if it installs it.