Date: Tue, 26 Sep 1995 02:33:45 -0500 (CDT) From: peter@taronga.com (Peter da Silva) To: hackers@FreeBSD.ORG Subject: Re: ports startup scripts Message-ID: <199509260733.CAA03239@bonkers.taronga.com> In-Reply-To: <199509260703.DAA15938@healer.com> from "Coranth Gryphon" at Sep 26, 95 03:03:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 6. setting up spool directories. > > You don't want these to be under /usr/local. > "mkdir /var/spool/NAME" ? mkdir $SPOOL_PREFIX/$PACKAGE_NAME > Do we really need to keep this information after the package is > installed? Sure. Every time you install a new package. Why? Because you regenerate the whole thing every time, rather than edit it. The *master* copies are in /etc/packages. And you rebuild all these files the same way for the sake of consistency. > Well, yeah, for uninstall purposes. Grrfff. Right. You uninstall by removing the package files, and rebuilding. > But then it's not GENERIC. OK, call it CURRENT. > Besides, just how much are we willing > to automate the install process? I think there comes a point > (and kernel rebuilding should be on the other side of that line) > where we either do everything for them, or tell them how to do > it an let them do it themselves. Kernel rebuilding on System V *is* automatic, and it works. The problem is their packaging is rather higgledypiggledy. Keeping this stuff in a common tree is much nicer. > A lot of other operatins sytems (SCO comes to mind) has the "package_add" > super util that does everything, including kernel rebuilds. If we want to > do that automated, make it one big intelligent tool (even if most of what > it does it call all the little tools we already built above :-) That's the scenario I'm talking about. Except I'm trying to avoid making the tool any smarter than it has to be, because the smarter it is the easier it is to break. It's pretty hard to break "concatenate these files". That's why I don't want to use "adduser". But see below... > > /etc/inetd.conf > > /etc/syslog.conf > > /etc/services > As mentioned above.... How do you upgrade if you never remove anything? What if I remove cern httpd and install apache? > I guess, for packages that sit an listen on serial lines. > But again, unless we go for the "do-everything" util, how > much do we want to automate? As much as we can without having too many special cases. So far I don't think I've got any... oh yes, there's the password file. If it's a special case anyway we can have "adduser" and "deluser" in install and remove. > Actually, we can implement either the control file mechanism or the > rcN.d subdir mechanism on top of this cleanly, since either is now > just generated information... Of course. I don't care if you build the control file from the rcN.d files otherwise. Just so long as it's generated. Generating files from base+extensions is easy. Editing files is hard, especially when they don't have consistent formats. I kinda like the idea of having /etc/rc.mk, run by "make". That way the individual startup files have complete dependency information, *and* if you fuck up and remove something that's dependant it can tell you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509260733.CAA03239>