[RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

[Florent Thoumie]

On Mon, Mar 29, 2010 at 7:58 AM, Matthias Andree <matthias.andree at gmx.de> wrote:
> Am 28.03.2010, 08:14 Uhr, schrieb Garrett Cooper:
>
>> Hi,
>>    As part of taking a look at the differences in our implementation
>> of pkg_install(1) in order to afford an improvement over the existing
>> code, I've looked at various implementations of pkg_install, one being
>> NetBSD's evolution [1]. It's several years ahead from our's and while
>> I don't believe that all of the complexity is desired, there's a lot
>> of good lessons to be learned from this. One of which is that they
>> replaced the @exec and @unexec calls with string pre-install //
>> post-install and pre-deinstall // post-deinstall scripts. I think that
>> this potentially is a good step forward because it takes some of the
>> guts out of the +CONTENTS files and places it in [bourne shell]
>> scripts, which are easier to maintain and potentially understand.
>>    I realize that some of the loss would be that one couldn't simply
>> specify things like %f, %D, %F, etc with @exec and @unexec, but that
>> seems a small price to pay for tuning everything a bit more. On the
>> plus side too, that means that one could use an extensive set of
>> shell, etc libraries that would avoid code duplication like what's
>> present in the +CONTENTS files. This is one of the small observations
>> I made after starting on work which would modify 1k python ports to
>> not install the byte-compiled or optimized files (side topic that we
>> can talk about in another thread if desired).
>> Thoughts?
>
> Hi Garrett,
>
> I'm not so sure what the advantage would be. For trivial
> pre-post-(de)install tasks, why use a separate script? It's less concise
> than reading everything in pkg-plist.
>
> WRT variables, I'm not so concerned about %D %F etc, but I am concerned
> about the necessity to add script boilerplate (such as snatching pre-post or
> deinstall-install modes, prefix), and while I haven't thoroughly audited the
> install scripts in ports, I see lots of bad shell scripts around. These
> would need rigorous audits (in adverse conditions, such as paths containing
> blanks and shell meta characters to unveil underquoted
> parameters/variables).
>
> Also, this effort alone isn't any help in reducing code duplication, as in
> my perception the duplication is between Makefile (for port install) and
> pkg-plist/pkg-install (for packages). There often is some line similar to
>
>  ${SETENV} PKG_PREFIX="${PREFIX}" ${SH} ${PKGINSTALL} ${PKGNAME}
> POST-INSTALL
>
> in the ports' Makefiles (post-install or whereever appropriate).
>
> Also, this would need excellent documentation. RPM on Linux is similarly
> flexible, but is severely underdocumented (at least RPM v3 and v4 on
> openSUSE Linux are). If it does any _undocumented_ magic, I don't want it.
> :)
>
> So, before we think about it and harrass hundreds of ports maintainers, we'd
> need the shell script library in place to make it a selling point for
> actually using install scripts; at that point we can re-think about moving
> stuff out of pkg-plist into pkg-install scripts. At the *same* time (so that
> only one edit cycle is needed for affected ports - and I'd suggest a survey
> to see how many, hundreds probably), we should consider making
> Mk/bsd.port.mk call the install scripts automatically (needs changes to
> hundreds of ports again) in pre-install, post-install and related stages.

I mentioned getting rid of those pesky @*exec lines a few years ago,
but this was met by quite a lot of objection.

I still think it would be a good change, assuming that we provide
equivalent (or better) features:

- Configuration files should be marked and automatically dealt with by
the infrastructure, not by esoteric commands.
- Subroutines for shell scripts should be provided along with
pkg_install, or be installed by a third party port (users/groups
creation comes to mind).
- Scripts should be automatically picked up as you mentioned. We're
trying to shove most targets in pkg-install, but it probably would be
best to split it (preinstall, postinstall, predeinstall,
postdeinstall). Good thing is, this doesn't require any change in
pkg_install since it's already supported.

One of the added bonus is that some code that appears both in Makefile
and pkg-plist will only be in preinstall/postinstall scripts.

-- 
Florent Thoumie
flz at FreeBSD.org
FreeBSD Committer