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

Garrett Cooper yanefbsd at gmail.com
Mon Mar 29 10:08:55 UTC 2010

On Mon, Mar 29, 2010 at 2:10 AM, Florent Thoumie <flz at xbsd.org> wrote:
> 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.

Let's put it this way. Once I determined that there was some
precompiled crud that needed to be removed in order to eliminate bugs
in python packages, that was a lofty goal that I intended to complete
~2 months ago.

Things happened, I got busy, then got back to it 2 weekends ago.

Now, I'm not miwi@ by any means, so modifying ports does require
proper motivation to complete, but let's put it this way... after
modifying 40 ports I said to myself `this is stupid.. I could reduce
the amount of useless typing by automating this crud through a script
library once and call it from the pkg_*install script, respectively,
without having to go through the error prone exercise of hand-editing
1000-some plists' -- because certain `package categories' have common
logic that can be applied to them when they're installed and removed.

>> 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).

It's really no better passing in these values in +CONTENTS [// *plist]
form because a lot of this stuff is fed through to vsystem eventually
[a pkg_install home-grown variadic version of system(3)], which means
that all bets are off then, minus the initial @cwd stuff (but that's
fine because it's handled from within pkg_install anyhow.

>> 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
>> in the ports' Makefiles (post-install or whereever appropriate).

This doesn't make sense to be honest... *sigh*. There's already a
well-established format in pkg_install that should be leveraged
instead of reinventing the wheel for ports...

>> 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.

No need; pkg_add and pkg_delete already do this and do it fairly well,
and pkg_install should be called from ports anyhow because it is the
package maintenance tool...

> 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.

    Exactly. pkg_create does properly document this functionality, but
unfortunately it's really underused in the ports infrastructure and
instead all of this stuff is jammed into the +CONTENTS [/*plist]. This
is what should be avoided because we've just made the plists into a
veritable 7-11 for all of the pkgs needs instead of using duplicated
    I was also hoping to converge into a more sensical model like
NetBSD has created over the past 4 years -- and this is one of the
gaps that I think we should cross in trying to make this possible. The
overall goal is to make a logically sound change that would reduce
maintenance for everyone in the ports community.

More information about the freebsd-ports mailing list