Date:        Thu, 30 Dec 2004 14:43:50 +0100 (CET)
    From:        Dieter Baron <dillo@danbala.ifoer.tuwien.ac.at>
    Message-ID:  <200412301343.iBUDhoM23315@danbala.tuwien.ac.at>

  |   Agreed.  When I want to install a server an run it, all that is
  | required should be:
  | =

  | * install package (make install or pkg_add)
  | * explicitly enable server (add a line to rc.conf (e.g. server=3DYES)=
)
  | * optionally override default settings in rc.conf (e.g. server_flags=3D=
--foo)
  | * start server (/etc/rc.d/server start)

You're willing (and what's more, wanting) to do all of that work, and
you're not willing to copy a file (or set an env var / mk.conf var to cau=
se
the copy to happen for you) ?   That's an interesting place to draw the l=
ine.

  | much in the same way as is done for servers in the base system.

The two cases are not the same at all.   Stuff in the base system gets
installed whether I want it or not - I don't ask for a ftp server, or
a MTA, or ...  they're just dumped on me.   So, for those, it is both
reasonable, and easy to understand, that the server needs to be explicitl=
y
enabled before it works (it is less easy to justify that some servers
get enabled in one way, and others in an entirely different way, but that=
's
not the issue now).

On the other hand, if I am explicitly installing apache, or cups, or ...
surely I want to use the thing, why else would I be installing it?

(Of course, I may be just building binary packages, but if I'm that
kind of user, I probably know how to set an option to prevent auto-start
of the new server).

  |   That might have a more complex semantic than you imply.  What about=

  | packages that provide more than one server, for instance?

SMOP.    That's not hard at all.


  | I don't think that would be a good idea.

I didn't really think that many people here would consider it a good
idea - the question is more what are the arguments against it, and
assuming they're good enough to win the debate, just how far away from
"automate everything" we get left.

  | Like with the base system,

Very poor analogy, let's just forget that one.

  |   Also, since such packages can be pulled in implicitly as
  | dependencies,

This is a very good argument for auto-start - if I need a package,
but didn't know I need it, then I'm not going to know that I'm supposed
to start it, am I?   So, if it is important enough to be a dependency
of something, then it really should be installed, and started, without
me having to do a thing - otherwise the package that I really wanted isn'=
t
going to function properly, is it?    (Aside: I know there are packages
that have bad dependencies like this, but they're just bugs, like broken
rc.d scripts, which should be fixed - we shouldn't be considering the
presence of bugs when we're deciding what is the correct approach, we
just fix those as we find them).

  |   Why?  They can't be run before $LOCALBASE is mounted anyway (as the=

  | servers they are trying to start reside there),

No, but the run order gets determined before anything else is done,
for packages that are, and are not, on filesystems mounted at boot
time (ie: for those that are on root, and all the others).

  | so I don't see the
  | technical necessity of having to read them before then.  (Yes, I am
  | aware that the rc subsystem is currently unable to handle this, but
  | that could be fixed.)

"Could be fixed" - fix this one first, then we'll talk about it.

  |   Why?  Just because the rc subsystem currently runs scripts in only
  | that directory?  That is even easier to change than reading them in
  | after mounting $LOCALBASE.

Sure, we could add more standard directories, but what does that really
gain us?   Just more places to have to go look to find things.   One plac=
e
is really enough (for standard installations, you can, of course, on
your system, put things as many places as you want).

  | : - and provide a mechanism to allow the user
  | : to override the default sequencing of this script in rcorder - that=
 is,
  | : to configure the REQUIRE and BEFORE headers of the script).
  | =

  |   Why would we need that?

Different people have different needs for what packages get started in
which order.   It's hard enough coming up with a reasonable order for the=

stuff in the base system (which really amounts to not much, without many
variations possible).   Attempting to have pkgsrc maintainers determine
the best possible start order for everything that might possibly be
installed, in any combination, is way beyond a reasonable requirement.

This is one reason why teaching people about the existence and location
of the startup script is not a bad thing - that way they know enough abou=
t
it to find it, and make changes - and is also a good argument for treatin=
g
the scripts supplied with pkgsrc as no more than examples.

kre