Date: Wed, 8 Jun 2005 16:38:02 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: "J.R. Oldroyd" <fbsd@opal.com> Cc: freebsd-rc@freebsd.org Subject: Re: Use of rcorder for local rc.d/*.sh scripts Message-ID: <20050608233802.GA29707@odin.ac.hmc.edu> In-Reply-To: <20050607191109.GU37208@linwhf.opal.com> References: <20050603143803.GP886@linwhf.opal.com> <42A4CA37.1050201@FreeBSD.org> <20050606235426.GA10526@odin.ac.hmc.edu> <20050607001447.GG37208@linwhf.opal.com> <20050607003142.GD10526@odin.ac.hmc.edu> <20050607033536.GH37208@linwhf.opal.com> <20050607160855.GO37208@linwhf.opal.com> <20050607173741.GI11758@odin.ac.hmc.edu> <20050607191109.GU37208@linwhf.opal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 07, 2005 at 03:11:09PM -0400, J.R. Oldroyd wrote: > On Jun 07, 10:37, Brooks Davis wrote: > > > So, if this approach were adopted, several > > > changes will be needed to all local rc scripts: > > > - any with a .sh suffix will need to be renamed from > > > "foo.sh" to "foo" > > > - any files like "*.sh.sample" will have to be moved > > > elsewhere, or made non-executable > > > - rcorder tags will need to be added to any that care > > > about the order of their execution, and names like > > > "000.*" can be eliminated > >=20 > > There is very little chance of getting this to fly. Remember, any > > solution has to work for all releases currently supported by ports. In > > practice, this currently means the security branches so anything that > > breaks existing localpkg based systems is not going to work. I think > > that keeping the .sh extension is going to be required for the > > foreseeable future. Requiring that rcorder runs on all the .sh files > > generate an appropriate order is probably a reasonable goal for 6.0. > > If we did that in 6.0, we could require the removal of non .sh files for > > 7.0 and remove the .sh extensions through a release dependent action in > > the RC_SUBR support in bsd.port.mk. In theory you could do the RC_SUBR > > changes for 6.0, but big changes to requirements for ports are very time > > consuming, especially if you are going to modify bsd.port.mk. > >=20 > > Any change of this order is going to require discussion on ports, and > > buy-in from portmgr. > >=20 >=20 > Is this as bad as you're suggesting? Possibly. :-| The curse of having nearly 13,000 ports is that changes in any significant portion are quite difficult if you have to have a flag day. It's by no means impossible, but it's a lot of work. > Agreed, requiring "foo.sh" be renamed to "foo" for so many ports > is a biggie, so perhaps we keep the *.sh for now, and arrange that > files in the local scripts dirs are run in a subshell from rc.subr, > rather than being sourced. This is probably important for security > reasons, anyway. It also keeps existing semantics, so should work > on all systems. >=20 > It also eliminates the issue with foo.sh.sample as such files > will continue to be ignored. I think we definitely want to keep the existing semantics of *.sh scripts being run for the time being, if not permanently. > We only need to add rcorder tags on ports which currently use > "NNN.foo.sh" scripts, and we could even delay this by introducing > an extra rc.conf flag to have /etc/rc execute any local NNN files > immediately after SERVERS or such suitable point. The trick is finding all of them. We don't currently have a plist database. It's something that needs to happen, but until it exists, finding all the rc files is an interesting challenge. It's probably not infeasible by 6.0 though if you can get kris to help you. > If you feel this is not the desired direction, let's revert back > to the "localpkg hack". My goal here was to simply introduce the > use of rcorder for local scripts so that those scripts which do > have tags can take advantage of them and thereby fix a problem > in which some things currently don't start. What I like about the localpkg hack is that it doesn't change much. I think you have solutions to most of my concerns though. My gut feeling is that full integration of /usr/local in rcorder is not feasible for 6.0, but localpkg with rcorder should be. Remember, feature freeze is nominally Friday. My suggestion would be to push for the localpkg hack and the port changes it requires for 6.0 so ports can depend on each other's services with the plan of doing full integration in 7.0. That would get the most critical feature working now and give us over a year to shake out any issues with full ordering. After a good period of settling, I think we could even MFC the localpkg hack to 5.x, probably in time for 5.5. If that, happened, I think we'd be able to fully mandate rc.d style scripts for 7.0 because all supported versions of FreeBSD would run rcorder on their scripts. BTW, thanks for working on this. It's a feature I've been wanting for some time now. As always the devil is the details. -- 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 --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCp4FZXY6L6fI4GtQRAhx6AJ9JefC/eGcFb0EF8VyJr848IkekTQCeM5fo ra5aMUQ2o8jEGubUftCAwZ0= =Em6W -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050608233802.GA29707>