From owner-freebsd-ports@FreeBSD.ORG Mon Mar 29 09:11:15 2010 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD311106566B for ; Mon, 29 Mar 2010 09:11:15 +0000 (UTC) (envelope-from florent.thoumie@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 47BBA8FC12 for ; Mon, 29 Mar 2010 09:11:14 +0000 (UTC) Received: by fxm25 with SMTP id 25so5575fxm.3 for ; Mon, 29 Mar 2010 02:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=BJxwPQKanEGbyrotnV/7s86NqNgrPEN28aYbBJaYG4o=; b=lyK2u6GEkvheSptXNwSl7a4vfBOV8uJc9q/48BDPXo3//aerEB/3XremvjKQEtX2fn 7M5JXMAu3/Mk2VoqkZyQ3226YRa8hSaxk0eQjtlJWiDoCX9WMTVSzFiRTENayfCkohUA 6452ccv/t3p3EOJXwgZDQxpi1mR0n8JWy0w8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=xHhH3Yhc3joOTIOSah7NzcCKkrectHgEjsrVIWCKCWUwFKyhCZhqcmj4iUJo27t+Ob mtJaewR1Qj6peEpymkz9L6W8ESAnHnqdTsQXsR1+m9IHz1cMw/mkajBqnCRW+d5JUbEW i+/QTKulaaNGUXsP+sVPWVgK+Q9PS2tVa7i7Y= MIME-Version: 1.0 Sender: florent.thoumie@gmail.com Received: by 10.239.182.206 with HTTP; Mon, 29 Mar 2010 02:10:54 -0700 (PDT) In-Reply-To: References: <7d6fde3d1003272314r25305a39mce9893e07453ef90@mail.gmail.com> From: Florent Thoumie Date: Mon, 29 Mar 2010 09:10:54 +0000 X-Google-Sender-Auth: 0837e069030dfcde Received: by 10.239.182.5 with SMTP id o5mr433581hbg.160.1269853874088; Mon, 29 Mar 2010 02:11:14 -0700 (PDT) Message-ID: To: Matthias Andree Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Ports , Garrett Cooper Subject: Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 09:11:15 -0000 On Mon, Mar 29, 2010 at 7:58 AM, Matthias Andree w= rote: > Am 28.03.2010, 08:14 Uhr, schrieb Garrett Cooper: > >> 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? > > 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 containi= ng > blanks and shell meta characters to unveil underquoted > parameters/variables). > > Also, this effort alone isn't any help in reducing code duplication, as i= n > my perception the duplication is between Makefile (for port install) and > pkg-plist/pkg-install (for packages). There often is some line similar to > > =A0${SETENV} PKG_PREFIX=3D"${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, w= e'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 movin= g > stuff out of pkg-plist into pkg-install scripts. At the *same* time (so t= hat > only one edit cycle is needed for affected ports - and I'd suggest a surv= ey > 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. 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. --=20 Florent Thoumie flz@FreeBSD.org FreeBSD Committer