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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to