Date: Sun, 23 Mar 2008 08:40:31 +0100 From: =?ISO-8859-1?Q?Eirik_=D8verby?= <ltning@anduin.net> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: stable@freebsd.org Subject: Re: Upgrading to 7.0 - stupid requirements Message-ID: <470FAA23-402B-4735-8C35-9897CA6C2589@anduin.net> In-Reply-To: <47E60695.2070507@infracaninophile.co.uk> References: <868x0ezh9u.fsf@zid.claresco.hr> <200803192028.m2JKSZen098816@lurza.secnetix.de> <20080323000707.GA33311@fupp.net> <b269bc570803222059o7b52c8d8p9fa0fdbfed273ba0@mail.gmail.com> <47E60695.2070507@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 23, 2008, at 08:28, Matthew Seaman wrote: > Freddie Cash wrote: > >> All that's really needed is a more formalised process for handling >> upgrading config files, with as much as possible managed via the >> ports >> framework itself. Something that dictates the name of the config >> file, and that compares the config file from the port against the >> installed config file (or against an md5 of the port config file) and >> only replaces it if it is unchanged. Something that is part of the >> make system. > > Most ports that install configuration files actually do this already. > It's generally why you'll find that a sample configuration file is > considered part of the port, but the actuall live configuration file > is not. The port will only feel free to meddle with the config file > if > it is still identical to the sample file. There are a few exceptions to this rule: The courier authdaemon ports, for instance, are notorious for overwriting my carefully-crafted configuration files when upgrading. I loathe those ports (or apps - not sure who's to blame) for that reason alone. In fact, it not only installs a config.dist file (which is fine), but it ALSO overwrites the current config. A cardinal sin, if there ever were any.. Now I must say I'm with the people who think that one should follow the one-port-one-configfile approach; however for a somewhat different reason: The closer a port sticks with the "default" configuration files, or samples if you will, of the software in question, the less FreeBSD-specific knowledge needs to be built to manage the port. If debian splits up the config into a forest of includefiles and symlinks, that might be good for a particular purpose, but it's something I'd prefer to do myself if the need is there. I've done similiar things on some occations, but that is, and IMO should be, "homebrew". Also, making ports adhere to a much stricter configuration regime would make the uptake of new ports slow down considerably. I believe (though I have no numbers to back this up, so it is of course pure speculation) that the large number of ports available is at least partly due to the fact that making an initial port is relatively easy and straight forward. Just my 2 cents. /Eirik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?470FAA23-402B-4735-8C35-9897CA6C2589>