Date: Mon, 29 Mar 2010 03:08:54 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Florent Thoumie <flz@xbsd.org> Cc: FreeBSD Ports <ports@freebsd.org>, Matthias Andree <matthias.andree@gmx.de> Subject: Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts Message-ID: <7d6fde3d1003290308m1cdde98dr1231b55ebad8f45c@mail.gmail.com> In-Reply-To: <a01628141003290210w45432af9o57a8a045d0bb92cb@mail.gmail.com> References: <7d6fde3d1003272314r25305a39mce9893e07453ef90@mail.gmail.com> <op.vabkfdrt1e62zd@merlin.emma.line.org> <a01628141003290210w45432af9o57a8a045d0bb92cb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 29, 2010 at 2:10 AM, Florent Thoumie <flz@xbsd.org> wrote: > On Mon, Mar 29, 2010 at 7:58 AM, Matthias Andree <matthias.andree@gmx.de>= wrote: >> Am 28.03.2010, 08:14 Uhr, schrieb Garrett Cooper: >> >>> Hi, >>> =A0 =A0As part of taking a look at the differences in our implementatio= n >>> 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 simpl= y >>> 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-pos= t 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 contain= ing >> 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 t= o >> >> =A0${SETENV} PKG_PREFIX=3D"${PREFIX}" ${SH} ${PKGINSTALL} ${PKGNAME} >> POST-INSTALL >> >> 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 i= t. >> :) >> >> 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 movi= ng >> 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 sur= vey >> 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 functionality. 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. Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d1003290308m1cdde98dr1231b55ebad8f45c>