Subject: Re: Summary: Third-party rc.d scripts
To: Tracy J. Di Marco White <gendalia@iastate.edu>
From: Frederick Bruckman <fredb@immanent.net>
List: tech-pkg
Date: 02/10/2002 10:46:57
On Sat, 9 Feb 2002, Tracy J. Di Marco White wrote:

> Frederick Bruckman <fredb@immanent.net> wrote:
> }It seems like there's finally a consensus brewing on where to install
> }the rc.d scripts, and I'd like to get on with that. As far as the
> }sharing ${PREFIX} situation goes, installing scripts directly into
> }/etc/rc.d shouldn't cause that much of a problem, as long as there are
> }no conflicts: you just "pax -r -w -pe -v /etc/{rc.d,defaults}/* ..."
> }to a shared directory periodically or after installing new packages.
>
> I've been behind on email, and only just started catching up.  I'm
> hoping I'd be able to set where they go with a variable or something,
> as I am planning to share packages between a large number of machines.
> (Granted, my plans don't have to be supported by NetBSD.) I'd prefer
> to be able to install the scripts in ${PREFIX}/etc, even if that isn't
> the default.

Of course, if you share ${PREFIX}/etc (the default), that path gets
baked into the binaries, and you're then unable to customize hosts.
That might be OK, at first, but it could get awkward for some cases.

> The example pax command could also be a large problem if the machines
> aren't running exactly the same version, as system rc.d scripts change
> between versions, are added and removed.

I see. How about this then:

1) Build your shareable packages to a ${DESTDIR}, set
${PKG_SYSCONFDIR} to ${DESTDIR}/etc, set ${PKGDB_DIR} to
${DESTDIR}/var/db/pkg, and export ${DESTDIR} read-only mountall to the
typical client. Such clients mount ${DESTDIR} when they need to update
their "/etc" files from the template ${DESTDIR}/etc, otherwise they
just mount "${DESTDIR}/usr/pkg" and "${DESTDIR}/usr/X11R6" (or mount
once, and symlink).

2) Designated clients, all of which run the oldest version of NetBSD
of all clients, mount ${DESTDIR} read-write, and do the actual
building. Other clients can happily run newer versions of NetBSD, as
long as their kernels have the appropriate COMPAT_ options, and they
have the appropriate libraries installed. Why _would_ you want to do
all your builds on your fileserver, while you have hundreds of
computers just heating up the the walls?

3) The server doesn't have to run the same version of NetBSD as the
clients. Give it it's own packages, built for whatever version of
NetBSD it has, that is most suitable to a file server. This means, for
example, you could update the file server without fear of losing hair
over making all the clients work with the new OS. You could even
replace the file server with new hardware and a newly built OS, and
the clients wouldn't have to know the difference.

> I would also be concerned
> (although this may be a lesser concern) about where you're installing
> these scripts on operating systems pkgsrc supports that aren't NetBSD.

OK. ${RCD_SCRIPTS_DIR} is already set conditionally, so it can be
easily overridden by the user. So is ${INSTALL_RCD_SCRIPTS} (to NO).
If we change the default to YES, that should be done in
defs.NetBSD.mk, and not in install/* directly. I'll have to look and
see if ${DESTDIR} will be respected properly. If not, it'll probably
just take a few ${DESTDIR}'s sprinkled in to make it so.

Frederick