Date: Thu, 19 Mar 1998 16:34:28 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Studded <Studded@dal.net> Cc: FreeBSD-hackers@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Discussion about script to update /etc, etc. Message-ID: <12479.890354068@time.cdrom.com> In-Reply-To: Your message of "Thu, 19 Mar 1998 16:17:57 PST." <3511B5B5.C9B61A37@dal.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, the ports freeze is tomorrow I think, so pardon me for being pushy. > :) Are you saying that you'd rather not move forward with a solution > like I've proposed? That's fine with me if the timetable for getting > something done about it will be less than two years. :) I don't mind I'm saying that the real solution here is to come up with something that encapsulates *all* the necessary information in a single file and then generate the "legacy" files from this one (perhaps only as a short-term thing, eventually phasing out the legacy files after people are comfortable with the other format). This would allow you to: 1. Express many things much more efficiently/powerfully than they are now - you wouldn't have to have a foo_enable, foo_command, foo_flags, etc. variables just to get foo to be customizable at startup, you'd simply have one "foo" with various properties attached in a more concise and powerful format than simple shell variables allow. 2. Separate the idea of "default value" and "changed value" for any given item, allowing truly automated merging of the "properties database." 3. Get past a number of evil limitations of the current scheme. Ever tried to put in ifconfig values for _multiple_ PCCARD ethernet cards, for example? Can't do it. How about configuring IPX values for an interface? Can't do it unless you abuse the "alias" mechanism. Or how about starting and configuring 3rd party things like upsd? You can start them (via /usr/local/etc/rc.d) but you can't set flags for them very easily. The list goes on. As the author of a number of the temporary bodges we're using right now (/etc/rc.conf and friends), I can say that they're exactly that - temporary bodges with numerous limitations. I was hoping we'd stop hacking out ever more temporary solutions to the /etc configuration problem someday and start thinking of something that actually SCALES worth a damn, but we clearly haven't gotten to that point yet. :) Jordan 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?12479.890354068>