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 underlyin=
g
  | 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.

The former yes, the latter, no, not necessarily - 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 coul=
d
include copying the rc.d file (as just one example) of what could be done=
=2E

  |  o There is no good reason that I can see that a default installation=

  |    from (pkg)source and a default installation from a binary package
  |    should result in a different result.

This I certainly agree with (with the obvious caveat, that binary package=

installation doesn't, and never will, allow all of the options that are
available to someone compiling from source).

The question is exactly what should happen when someone (na=EFve 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 ...).   Thi=
s
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:=3DNO}

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

	: ${cups:=3DYES}

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

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, and they have to be in a directory
that is used by the standard startup scripts - which means they have to
be installed in /etc/rc.d (and then we also have to sensibly handle
duplicate script names - 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).

[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.]=


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
(and when a package is deleted, logically, the script should be run
with "stop" to shut things down first).

Even that isn't enough though, there are packages that need more than
"just start" - some require other packages (or system default application=
s)
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=3DYES from rc.conf, or override it securely).

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.

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.

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

kre