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,

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.

freebsd-stable@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"