Don't Overwrite Config files

Teddy Thomas tthoma24 at mit.edu
Fri Jan 27 01:51:02 UTC 2017


Josh-

Thank you for your reply. I think I may not have been clear in what I'm
doing, so let me try to clarify in case it changes the answer. The config
files I'm dealing with arenot a configuration file for a port, it's
configuration files *provided by* a port, for use by the system.
Specifically, SSH and Kerberos config files for use in an institutional
deployment. It does not scale to make every user in the organization have
to manually move the config files to the correct place. What would you
suggest here? Any assistance would be most appreciated.

-Teddy

---------- Forwarded message ----------
> From: Joshua Root <jmr at macports.org>
> To: Teddy Thomas <tthoma24 at mit.edu>, MacPorts Development <
> macports-dev at lists.macports.org>
> Cc:
> Date: Wed, 18 Jan 2017 16:49:42 +1100
> Subject: Re: Don't Overwrite Config files
> On 2017-1-18 15:25 , Teddy Thomas wrote:
> > I’m trying to write a Macport that will install some config files in
> > /etc, and I’m wondering what the best way is to prevent overwriting user
> > customized files is, and to put the system config files back the way
> > they were when uninstalling the port. I looked in the Portfile best
> > practices (https://guide.macports.org/chunked/development.practices.html
> > <https://guide.macports.org/chunked/development.practices.html>) and
> > found section 4.7.2, but it’s listed as a TODO. Any insight anyone can
> > provide would be most appreciated. I’d be happy to contribute
> > documentation with a way forward. Thanks in advance.
>
> <https://trac.macports.org/wiki/PortfileRecipes#configfiles>
>
> Ports should in general keep their configuration files in ${prefix}/etc,
> not /etc. Modifying system config files tends to be a bad idea, not
> least because they may be modified by users and OS updates, so putting
> them back the way they were is not necessarily correct. Not changing
> existing files and letting the user deal with updating them is about the
> only tractable approach.
>
> - Josh
> _________________________
> macports-dev mailing list
> macports-dev at lists.macports.org
> https://lists.macports.org/mailman/listinfo/macports-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170127/64fbbaf0/attachment.html>


More information about the macports-dev mailing list