Date: Sun, 28 Mar 2010 13:15:34 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: FreeBSD Ports <ports@freebsd.org> Subject: Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts Message-ID: <7d6fde3d1003281315g576c82e6vecdf8ef6e61c877c@mail.gmail.com> In-Reply-To: <7d6fde3d1003272314r25305a39mce9893e07453ef90@mail.gmail.com> References: <7d6fde3d1003272314r25305a39mce9893e07453ef90@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 27, 2010 at 11:14 PM, Garrett Cooper <yanefbsd@gmail.com> wrote=
:
> Hi,
> =A0 =A0As 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.
> =A0 =A0I 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
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d1003281315g576c82e6vecdf8ef6e61c877c>