From owner-freebsd-ports@FreeBSD.ORG Thu Oct 30 14:52:54 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5972B739; Thu, 30 Oct 2014 14:52:54 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93150609; Thu, 30 Oct 2014 14:52:53 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gq15so4447316lab.7 for ; Thu, 30 Oct 2014 07:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6LE1RMKH/oB1BoXtv0SRNKY0tVmzPHKFWZDw+09jhm8=; b=WeAREcLN9NOTmEk3mUe7JXdPCB/WzNGhjH+y1Vt09r3k7RafOGh/jih7pf+3j5PjWa 2S5SgVvkYS/C5o1YHJj45pnQmf2C7pP0/uj0DtiPeviTzhwCBqbxojdGxST58YDTOE2I stZYvubQwn4EMH3Snfv06bJSVmJfXpHq7QhRRsGgRPCV3zpOqN0CPrvFiFXqcVP+HJRk DaeFrtDSRm5a6jdNUxauiduEylUSHHjcciQESKldA5XG3zfsPtX3c5gAstAXqZ/zQvyQ VqzlN0o6kx4CghdE5RN6Hzdkw0OzJDfSs6jZtk9ACaewsRrQwPo8yC3WY2Ku2f/QRtXd q0tg== MIME-Version: 1.0 X-Received: by 10.152.5.201 with SMTP id u9mr1150310lau.24.1414680771398; Thu, 30 Oct 2014 07:52:51 -0700 (PDT) Received: by 10.25.15.93 with HTTP; Thu, 30 Oct 2014 07:52:51 -0700 (PDT) In-Reply-To: <20141030004434.GS11033@ivaldir.etoilebsd.net> References: <20141029200212.GE11033@ivaldir.etoilebsd.net> <20141030004434.GS11033@ivaldir.etoilebsd.net> Date: Thu, 30 Oct 2014 07:52:51 -0700 Message-ID: Subject: Re: pkgng "requirements" script equivalent From: Nick Rogers To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-ports@freebsd.org" X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 14:52:54 -0000 On Wed, Oct 29, 2014 at 5:44 PM, Baptiste Daroussin wrote: > On Wed, Oct 29, 2014 at 01:43:27PM -0700, Nick Rogers wrote: > > On Wed, Oct 29, 2014 at 1:02 PM, Baptiste Daroussin > > wrote: > > > > > On Wed, Oct 29, 2014 at 12:44:21PM -0700, Nick Rogers wrote: > > > > Hello, > > > > > > > > I am in the process of upgrading some proprietary software that has > > > always > > > > been deployed via a "custom" package created by the old pkg_create. > So > > > far > > > > I've been able to use "pkg create" to achieve what I want, but it > seems > > > > that the "requirements" script is no longer a part of the new pkg > > > > framework. This used to be a script that you could include with a > package > > > > that could halt the pkg add or remove process by returning a non-zero > > > exit > > > > code from the script. I've been using it with the old pkg tools as a > way > > > to > > > > enforce some proprietary requirements logic that goes beyond > requiring > > > > certain pkg dependencies, architecture, etc. One example is to make > sure > > > a > > > > specific custom kernel is running by analyzing uname output. > > > > > > > > I am wondering if anyone has a suggestion as to how to interrupt the > pkg > > > > add process in a similar way. It looks like the "requirements" > script has > > > > been removed entirely, and from what I can tell a failure in the > > > > pre-install script does not halt pkg add. > > > > > > What is the requirement script you are speaking about? I never heard > of it? > > > > > > > man pkg_create(1) > > > https://www.freebsd.org/cgi/man.cgi?query=pkg_create&apropos=0&sektion=1&manpath=FreeBSD+8.3-RELEASE&arch=default&format=html > > -r rscript > > Set rscript to be the ``requirements'' procedure for the package. > > This can be any executable program (or shell script). It will be > > invoked automatically at installation/deinstallation time to > > determine whether or not installation/deinstallation should pro- > > ceed. To differentiate between installation and deinstallation, > > the keywords INSTALL and DEINSTALL are passed respectively, along > > with the package's name. > > > > > > > Explain me in detail the way you were producing the package with > > > pkg_create and > > > I'll explain you how to do the same with pkg(8). > > > > > > > I was running pkg_create with the following arguments: > > > > pkg_create -f plistfile -c -'comment' -d -description' -v -P 'list of > > dependency packages' -v -r requirements_script_file -i > > pre-install_script_file -I post-install-script_file -k > > pre-deinstall_script_file -K post-deinstall_script_file -s > > /space/build/trunk -D displayfile -p /space/rxg -o category/name pkg.tbz > > > > For the most part I've figured out the appropriate +MANIFEST file and > > manifest directory contents, except for the "requirements procedure" > script. > > > > Ok requirements are gone, and you have a perfectly justified use case, I > will > readd such functionnality as soon as I can when dealing with binary > upgrade it > is basically a wrong idea to fail the procedure because a script fails so > I need > to add the notion of trigger and run the requirements prior the procedure. > > Might be complicated to add but it is for sure something we need. > > I cannot promise anything for pkg 1.4 which is in freeze time but I'll try > to > see what I can do. > Yeah that is what I suspected. I will probably find a way to accomplish what I am doing some other way (i.e., outside of pkg), as I am trying to get this working for upcoming 10.1-RELEASE. However it would be nice to have a requirements procedure again sometime in the future. Thanks! > regards, > Bapt >