Date: Fri, 10 Nov 2000 19:26:05 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: root@virtual-voodoo.com (Charlie &) Cc: so@server.i-clue.de (Christoph Sold), olgeni@uli.it (Jimmy Olgeni), hackers@FreeBSD.ORG Subject: Re: What about rc.shutdown.local? Message-ID: <200011101926.MAA25495@usr08.primenet.com> In-Reply-To: <20001109102337.A64659@virtual-voodoo.com> from "Charlie &" at Nov 09, 2000 10:23:37 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > It would be nice to have a /etc/rc.shutdown.local called by > > > /etc/rc.shutdown, > > > to implement custom shutdown procedures. This is currently done by > > > editing rc.shutdown, but you have to remember about it when you run > > > mergemaster. > > > > Better still would be /usr/local/etc/rc.d/*.sh called automatically > > with parameter stop. To do so, insert > > This already happens... at least in rc.shutdown v1.15: > > # $FreeBSD: src/etc/rc.shutdown,v 1.15 2000/10/20 20:26:05 ache Exp $ I was looking for a similar thing yesterday, and had to roll my own. The problem with the /usr/local crap is that it assumes that anything I'm going to install will be put into the /usr/local. The basic problem with this assumption (and of the runtime linker not seeing shared libraries in directories that are not in ldconfig, but were used in the build process to link successfully, and have their paths therefore stored in the binary) is that it assumes that I will never have a conflict with the system. Unfortunately, the ports system likes to use /usr/local to dump ports in, so this makes for a certain amount of developement confusion. When I want to develop a program on a FreeBSD system to deploy on a FreeBSD system, I will install all sorts of ports on my developement machine, but I will install nothing but the code I wish to deploy on my deployment machine. This means that the deployment code may infact use some of the same libraries and other binaries and data and so on that result from the ports system installing packages and ports, BUT it can NOT depend on these libraries being present in the deployment environment. This means that my deployment code my target a different directory hierarchy. The "ldconfig" issue aside (it's a can of worms, including that I could end up linking system components against my developement components because of ldconfig, even though I will later move or delete the build product), this is a real problem. For the startup stuff, at least you can wedge it with a /etc/rc.local; I know that it's "preferred" that I put my code and the ports code into the same namespace, but it is not "preferred" by me, nor is it really practical to do an extreme audit of every bit of code to make sure that I'm not getting a header file or something "accidently" by way of /usr/local. Worse, what if my deployment system is not FreeBSD? I know, I can hear the cries of "Heresy!" from here. I need to ensure that I can build out my source tree without dependency on the host system at all, at least as far as things in addition to POSIX interfaces and the libraries that implement them, let alone crap that some port happens to import "behind my back" to satisfy some third or fourth order dependency. So for FreeBSD, it would be useful to have an rc.shutdown.local which corresponds to rc.local, and the "preference" of the style police be damned. It seems to me that FreeBSD is setting itself up to be a system on which all working software needs to be integrated into the ports system, and this won't work at all for commercial or role modularized code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011101926.MAA25495>