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

Garrett Cooper yanefbsd at gmail.com
Sun Mar 28 20:15:35 UTC 2010

On Sat, Mar 27, 2010 at 11:14 PM, Garrett Cooper <yanefbsd at gmail.com> wrote:
> 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?

    And since kimelto asked on IRC, here's why byte-compiled python
files are bad in packages...

23:20 <@kimelto> gcooper: what's the point about byte compiled python files?
23:24 <@gcooper> kimelto: 1) it blows up the package size
23:24 <@gcooper> 2) on some versions of python it disguises bugs with
__file__ because byte-compiling embeds
                 values of certain variables evaluated at compile time
23:25 <@gcooper> 3) it adds more crap to the plists


More information about the freebsd-ports mailing list