What is policy about auto-editing config files on port install / deinstall?

[Paul Schmehl]

--On January 3, 2013 1:12:43 PM +0100 Fabian Keil 
<freebsd-listen at fabiankeil.de> wrote:

> Scot Hetzel <swhetzel at gmail.com> wrote:
>
>> On Wed, Jan 2, 2013 at 2:37 PM, Miroslav Lachman <000.fbsd at quip.cz>
>> wrote:
>> > Is somewhere written policy or portmgr recommendation about ports
>> > behavior on install / deinstall?
>
> My impression is that every maintainer has her own undocumented
> policy although the approaches taken could be grouped into a few
> categories.
>

This is likely true, however the Porters Handbook describes the preferred 
methods for doing things. 
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html>

>> > I am talking about some ports doing "nasty" things.
>> >
>> > Some ports are stopping services on deinstall, some not.
>>
>> I prefer that when a port is uninstalled, that the service is stopped.
>

According to the Porters Handbook, this is not the preferred method:

"6.24.1 Stopping Services at Deinstall

It is possible to have a service stopped automatically as part of the 
deinstall routine. We advise using this feature only when it is absolutely 
necessary to stop a service before its files go away. Usually, it is up to 
the administrator's discretion to decide, whether to stop the service on 
deinstall or not. Also note this affects upgrades, too.

A line like this goes in the pkg-plist:

@stopdaemon doormand

The argument must match the content of USE_RC_SUBR variable."
>
>> > Some ports are editing "my config files" on deinstall, so even on
>> > upgrade procedure I must check if port did some changes before I can
>> > restart target daemon.
>> >
>> Most ports don't edit the config files as they install the original
>> config file to a different name.
>
> In my opinion ports shouldn't mess with user-modified files unless
> they properly parse them and can be expected not to break them.

The Porters Handbooks explicitly states this:

"7.3 Configuration Files

If your port installs configuration files to PREFIX/etc (or elsewhere) do 
not simply list them in the pkg-plist. That will cause pkg_delete(1) to 
remove the files carefully edited by the user, and a re-installation will 
wipe them out.

Instead, install sample file(s) with a filename.sample suffix. Then copy 
the sample file to the real configuration file name, if it does not already 
exist. On deinstall delete the configuration file, but only if it is 
identical to the .sample file. You need to handle this both in the port 
Makefile, and in the pkg-plist (for installation from the package).

Example of the Makefile part:

post-install:
	@if [ ! -f ${PREFIX}/etc/orbit.conf ]; then \
		${CP} -p ${PREFIX}/etc/orbit.conf.sample ${PREFIX}/etc/orbit.conf ; \
	fi

For each configuration file, create the following three lines in pkg-plist:

@unexec if cmp -s %D/etc/orbit.conf.sample %D/etc/orbit.conf; then rm -f 
%D/etc/orbit.conf; fi
etc/orbit.conf.sample
@exec if [ ! -f %D/etc/orbit.conf ] ; then cp -p %D/%F %B/orbit.conf; fi

The order of these lines is important. On deinstallation, the sample file 
is compared to the actual configuration file. If these files are identical, 
no changes have been made by the user and the actual file can be safely 
deleted. Because the sample file must still exist for the comparison, the 
@unexec line comes before the sample configuration file name. On 
installation, if an actual configuration file is not already present, the 
sample file is copied to the actual file. The sample file must be present 
before it can be copied, so the @exec line comes after the sample 
configuration file name.

To debug any issues, temporarily remove the -s flag to cmp(1) for more 
output.

See pkg_create(1) for more information on %D and related substitution 
markers.

If there is a very good reason not to install a working configuration file 
by default, leave the @exec line out of pkg-plist and add a message 
pointing out that the user must copy and edit the file before the software 
will work."

>
> And even then I don't think it should be done automatically without
> user interaction.
>
> I believe that's currently up to the maintainer as well, though.
>

Not if they are properly following the Porters Handbook and the committers 
are verifying that they are doing so.

As with any system where humans are involved, the process is flawed. 
However, there is a right way to do things.  Refer to the Porters Handbook 
and follow its instructions as much as is humanly possible.

-- 
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
*******************************************
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell