Upgrading to 7.0 - stupid requirements

Eirik Øverby ltning at anduin.net
Sun Mar 23 00:58:24 PDT 2008


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


More information about the freebsd-stable mailing list