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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"

Reply via email to