Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jun 2005 10:27:40 -0700
From:      Brooks Davis <brooks@one-eyed-alien.net>
To:        "J.R. Oldroyd" <fbsd@opal.com>
Cc:        Doug Barton <dougb@FreeBSD.org>, freebsd-rc@FreeBSD.org
Subject:   Re: Use of rcorder for local rc.d/*.sh scripts
Message-ID:  <20050614172740.GC20371@odin.ac.hmc.edu>
In-Reply-To: <20050614134732.GB16676@linwhf.opal.com>
References:  <20050609050517.GA28710@odin.ac.hmc.edu> <42A89CD7.1080404@FreeBSD.org> <20050609201017.GA10248@odin.ac.hmc.edu> <42A8A91B.8000402@FreeBSD.org> <20050609210223.GB16168@odin.ac.hmc.edu> <20050612121504.K844@ync.qbhto.arg> <20050613005533.GA28966@odin.ac.hmc.edu> <42AD19C9.2040403@FreeBSD.org> <20050613155211.GB19722@odin.ac.hmc.edu> <20050614134732.GB16676@linwhf.opal.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--pAwQNkOnpTn9IO2O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 14, 2005 at 09:47:32AM -0400, J.R. Oldroyd wrote:
> It seems to me that TWO changes will be needed to make this transition.
> The transition modifies the semantics of how files in the local rc.d
> dirs are handled.
>=20
> Right now, local "foo.sh" files are executed in a subshell.
>=20
> After we're done, we want "foo" to be executed in a subshell and
> "foo.sh" to be sourced.  There are possible negative consequences
> of sourcing all "foo.sh" files, so two changes will probably be
> needed, one now in the short term which adds the rcordering
> capability and preserves other semantics, and one later on which
> brings all semantics into line.  Something like this:

I think this is a sensable proposal.  B or a similar variant should be
easily achievable by 6.0 and a fuller version could probably be
available for the first "production ready" release slated for January.=20

> A. NOW:
> 	/etc/rc.d	rcordered with "foo" run in subshell and
> 			"foo.sh" sourced
> 	local dirs	"foo.sh" run in subshell from localpkg
> 			in alphabetical order
>=20
> B. SOON:
> 	/etc/rc.d	rcordered with "foo" run in subshell and
> 			"foo.sh" sourced
> 	local dirs	"[0-9]foo.sh" scripts are run in a subshell
> 			first, then "[^0-9]foo.sh" and executable
> 			"[^0-9]foo" scripts run rcordered and run in
> 			subshells; "foo.xyz" (e.g., ".sample") ignored?
> 	ACTION required of port maintainers: NONE

One concern I have here is what does first mean?  It seems like we may
need to run as early as immediatly after mountcritremote which does
change the order a bit and would require a new rc script, something like
localpkg-early.

I'm not quite sure about the exclusions for rcorder.  The *.* exclusion
seems like an easy way to avoid *.sh, *.sample, *.orig, *.bak, etc.  I'm
not sure what the point of the [^0-9] is though, it would seem that the
logical migration path would be for users to add appropriate dependency
tags to their scripts and set a ports Makefile variable to cause the .sh
to be stripped when installing on appropriate versions of FreeBSD.
Removing the ### bits could be done after the flagday.

I'd be strongly tempted to require the documented rcorder pattern be
matched by the script in addition to the other exclustions.  We should
have egrep at this point so that should be easy.

I'd like to whine about any files that aren't run, probalby in localpkg.
It's fairly easy to do and would provide a push to get rid of the
various .sample bits.

> C. AT FUTURE FLAGDAY:
> 	/etc/rc.d+local	rcordered with "foo" run in subshell and
> 			"foo.sh" sourced; "foo.xyz" files now treated
> 			as "foo"
> 	ACTION required of port maintainers:
> 			- add rcorder tags to all scripts
> 			- rename "foo.sh" to "foo" unless sourced
> 			  behavior is desired

I think we should be able to automate this via USE_RC_SUBR and/or
RC_ORDER.

> 			- rename "[0-9]foo.sh" scripts to something
> 			  more suitable
> 			- move "foo.xyz" (e.g., ".sample") files
> 			  elsewhere

In preperation for this, it would be helpful if we could write port
post-install checks that kris could use to generate lists of ports that
need to be moved to the new standard.  There's no need to do this now,
but it's something to keep in mind.

> My thought is that to oblige port maintainers to make changes in
> the short term will be hard.  Give them some time (between points
> B. and C. and acceptance of the change will be a lot easier).
>=20
> So let's provide intermediate rc, rc.subr and localpkg scripts that
> may be larger and more complex, but which don't place an immediate
> burden on 13,000 port maintainers.  Then provide a final set of
> scripts which do.  The intermediate scripts can provide warning
> messages that alert that a change may be needed.

I agree.  I'd like to do the spadework to make the major benefits
available for 6.0 and then take the time between 6.0 and 7.0 to work
towards the flag day.  There's no reason not to make the full transition
in ports before 7.0 so all the flagday does is make old junk stop
working, as long as we do the work to warn about old style bits from
the beginning.

-- Brooks

--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

--pAwQNkOnpTn9IO2O
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCrxOLXY6L6fI4GtQRAtXqAJ9ZMbCk8yEy8LdJoevbYmjHFfw/9gCfdtQD
KkAZNWDsRnJ3mgI06/fB3rM=
=WYF1
-----END PGP SIGNATURE-----

--pAwQNkOnpTn9IO2O--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050614172740.GC20371>