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

[Matthias Andree]

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.

HTH

-- 
Matthias 'mandree@' Andree
FreeBSD ports committer