In article <13341.1104403929@munnari.OZ.AU> Robert wrote:
:     Date:        Wed, 29 Dec 2004 12:42:10 +0100 (CET)
:     From:        Havard Eidnes <he@uninett.no>
:     Message-ID:  <20041229.124210.112259642.he@uninett.no>

:   | It seems to me that there the goals underlying the current discussion
:   | have not been explicitly stated, and that too manu unstated underlying
:   | assumptions are being taken into account.

: I agree with that, and I'd like people to make clear exactly what the
: goal should be.

:   |  o It should be straight-forward to add and enable use of services
:   |    provided by binary packages.  This clearly means that manual
:   |    copying of rc.d files because they were installed "somewhere else"
:   |    is going in the wrong direction.

  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=YES))
* optionally override default settings in rc.conf (e.g. server_flags=--foo)
* start server (/etc/rc.d/server start)

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

: [...] it depends upon just
: how the "add and enable" stuff is handled.   That is, we could easily
: have a "pkg_enable" command that actually enabled an installed package
: (installed from pkgsrc or binary via pkg_add) which did whatever was
: necessary (including running pkg supplied enable scripts) - that one could
: include copying the rc.d file (as just one example) of what could be done.

  That might have a more complex semantic than you imply.  What about
packages that provide more than one server, for instance?

: The question is exactly what should happen when someone (naïve user)
: installs a package (using either pkg_add or make install in pkgsrc).

: Let's start with perhaps the limiting case, as something of a strawman
: to debate.    My guess would be that having installed a package that
: the user expects that now it "just works" - that's certainly true already
: for most of the packages (stuff like xv, or psify, or TeX, or ...).   This
: set mostly don't include packages that use rc.d files of course.

: If that's the expectation that we're to meet, then much of what is being
: proposed here is certainly not the right way to do it.   In particular,
: using a default of ...

:         : ${cups:=NO}

: (whatever syntax is used to express that) is clearly wrong, it would
: want to be

:         : ${cups:=YES}

: otherwise the package doesn't "just work" when it is installed.

  I don't think that would be a good idea.  Like with the base system,
I think the default should be not to start the server unless it is
explicitly enabled.  As with the base system, I think this explicit
enabling should be done with adding a line like cups=YES to
/etc/rc.conf.

  There are packages that install more than just a server: some also
install programs or libraries that are usefull even if the server is
not run on the same machine, some install more than one server.

  Also, since such packages can be pulled in implicitly as
dependencies, automatically starting the server is both dangerous from
a security standpoint and violates the principle of least surprise in
many cases.

: What's more ...

:         So I don't see why rc.d scripts should be any different --
:         just install them to $LOCALBASE/etc by default [...]

: also can't be what is done, as there's no way to reliably make
: scripts installed in $LOCALBASE/etc work properly - they have to
: get installed in the root filesystem,

  Why?  They can't be run before $LOCALBASE is mounted anyway (as the
servers they are trying to start reside there), 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.)

: and they have to be in a directory
: that is used by the standard startup scripts - 

  Agreed.  I think that is the whole point of this exercise.

: which means they have to
: be installed in /etc/rc.d

  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.

: (and then we also have to sensibly handle
: duplicate script names

  True.  Maybe we should avoid having name conflicts between the base
system and pkgsrc.  Or we should provide a mechanism to 

: - 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?

: [Aside: incidentally - the recent change that sparked this debate was,
: as I understand it, a trivial change to fix the problems caused by
: installing into $LOCALBASE/etc - people actually expected that to "just
: work" and it "just doesn't".   That's why the directory the scripts
: install into was renamed to "examples" - that's all that happened, the
: $LOCALBASE/etc/rc.d directory was just a directory of example scripts
: anyway - unless you locally modified your system to make it more, which
: you could, if you wanted, do with the examples directory just as easily.]

  [I guess it just reopened an old wound: some of us are unhappy with
the way rc.d scripts are handled in pkgsrc.]

: Of course there's more to "just work" than installing an rc.d script
: (which defaults to enabled, not disabled) in the correct directory - that
: script also needs to be run with a "start" argument, so whatever is
: supposed to happen at reboots, also happens now at installation time

  As I don't want it to be enabled by default, that is not necessary.

: (and when a package is deleted, logically, the script should be run
: with "stop" to shut things down first).

  That is probably a good idea.

: Even that isn't enough though, there are packages that need more than
: "just start" - some require other packages (or system default applications)
: stopped before they can start (pkgsrc postfix or sendmail for example,
: probably exim and qmail as well - and perhaps our example above (cups)
: and LPRng need similar changes made if they're to "just work"), so
: we have to handle that too (as well as disabling those sub-systems from
: restarting at the next boot - that is, something needs to be able to
: remove sendmail=YES from rc.conf, or override it securely).

  That is true for switching between MTAs that come with the base
system as well, so a sysadmin trying to do this should know about it.

  But maybe we should not select mutually exclusive choices with
enable/disable lines for each one.  Maybe something like this would be
better:

mta=YES
mta_system=sendmail

and a /etc/rc.d/mta script that runs the corresponding script
(sendmail in this case).  But that is beyond the scope of the current
thread.

: Now, it is my guess that the majority of people on this list don't want
: installing a package like this to "just work" in this way.    But
: perhaps they do?    In any case, we need to find out if we want this
: first.

  I would say we don't want it.

: If the answer is "no", then we need to work out just how much of
: "not quite ready to work yet" we're prepared to tolerate when a package
: is installed.

  See beginning of the post for my take on this.

: If the answer is "yes" there's a lot more to do than simply changing the
: default of PKG_RCD_SCRIPTS to "YES".

						yours,
						dillo