Propose new macro: INSTALL_CONF

[Chris Rees]

On 15 May 2011 23:59, Olli Hauer <ohauer at freebsd.org> wrote:
> On 2011-05-16 00:12, Chris Rees wrote:
>> Is this the Right Thing though, or a hack around missing code? You've
>> just hardcoded a mode in that people might not like.
>
> It is a hack to overcome the 444 mode and I used it only for some config files
>
>> Also, do you install the .sample like that, or do you use it to copy
>> the .sample to the actual config file? .sample files shouldn't be +w.
>
> It depends, how the files are installed.
> Some ports install everything with the scripts in the source
> (example: nagios/postfix ...) the only way is to patch this scripts
> and install/copy later the .sample to a .config if .config does not exist.
>
> Some will be installed by ${COPYTREE_SHARE} or other methods since
> they have a lot of files.
>
> In post-install now the trick is to lookup if there is already a
> .conf file before overwriting with the .sample which makes users
> unhappy if you destroy a existing config.
>
>> What do you put in pkg-plist?
>
> pkg-plist example
>> @unexec if [ -f %D/etc/PortName.conf ] && cmp -s %D/etc/PortName.conf %D/etc/PortName.conf-sample; then rm -f %D/etc/PortName.conf; fi
>> etc/PortName.conf-sample
>> @exec if [ ! -f %D/etc/PortName.conf ] ; then cp -p %D/%F %B/PortName.conf; fi


Aha, so here is my point about gymnastics in pkg-plist needed!


> The filemode is preserved, no need for pkg-install script
> But there are situations I don't like for example if a port has
> full write access to www/PortName since the maintainer decide to
> do a chown www:www %%WWWDIR%%
> Example solution: net-mgmt/nagvis/files/pkg-install.in
>
>
>>> and for sensitive config files
>>> ${INSTALL} or ${INSTALL_DATA} -m 640 -o ... -g ...
>>
>>> For config dirs (in the Makefile)
>>> PLIST_DIRSTRY=  %%ETCDIR%%
>>
>> This I'll concede!

Thinking about this, the CONF_DIRS hook creates the directories as
well as putting them into pkg-plist, but we can work on that.


>>
>>> This seems easier to me.
>>
>> It certainly doesn't seem easier to me; instead of:
>>
>> CONF_FILES= source:dest
>>
>> you still have to have a post-install bit, an @exec line in pkg-plist
>> with weird hieroglyphs, and an @unexec line _for each config file
>> installed_
>>
>> Can anyone explain why we bend over backwards to make ports
>> DATADIR-safe for example but completely ignore the user's preferences
>> with config files???
>
> No, I cannot explain but those macros are also used for a long time
> in the auto-scripts (autoconf/automake)


So, instead of my suggestion of this ONE line:

CONF_FILES=${WRKSRC}/${PORTNAME}.conf:etc/${PORTNAME}.conf



it's somehow EASIER to:

in install:
      @${INSTALL_DATA} ${WRKSRC}/${PORTNAME}.conf \
             ${PREFIX}/etc/${PORTNAME}.conf.sample

post-install:
       @[ ! -f ${PREFIX}/etc/${PORTNAME}.conf ] \
            && cp -p ${PREFIX}/etc/${PORTNAME}.conf.sample \
                  ${PREFIX}/etc/${PORTNAME}.conf


pkg-plist:

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


a total of 8 lines in two different files, and that STILL leaves us
with the WRONG permissions on ${PORTNAME}.conf!

If you look at the patch, as you've mentioned (thanks!), you'll see
that this is a simple way of automating these fiddly procedures as
well as making it more maintainable should the config file change name
/ other unforseen circumstances.

There is no real change to the outcome, we still end up with those
lines in pkg-plist, but crucially it doesn't have to be done by hand,
and it also doesn't have to be stored in the ports tree either.


Thinking about it from a size perspective, were everyone to adopt this
method we can assume an *average* of 100 B saving in each port, that's
2MB saved over the ports tree -- obviously it'll take a long time to
filter in assuming people would change it (which most probably won't,
but new ports/changes should), but code duplication is generally
frowned upon, is it not???

>
>> I just don't understand how the priority lies here.
>>
>> Chris
>
> If I find the time I will test your patch with some ports
> to get a feeling for it.
>

That's very kind, thanks! Don't forget CONF_FILES conflicts with some
ports, so be careful which ones you try!

Chris