From sacadmin Wed Apr 21 08:43:10 2010 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3LFhAv8007337; Wed, 21 Apr 2010 08:43:10 -0700 (PDT) Received: (from johnf@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o3LFhA25007333; Wed, 21 Apr 2010 08:43:10 -0700 (PDT) Date: Wed, 21 Apr 2010 08:43:10 -0700 (PDT) From: John Fischer Message-Id: <201004211543.o3LFhA25007333@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: Laszlo.Peter@Sun.COM Subject: pkgbuild build engine [PSARC/2010/138 FastTrack timeout 04/28/2010] Status: RO Content-Length: 599 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: pkgbuild build engine 1.2. Name of Document Author/Supplier: Author: Laszlo Peter 1.3 Date of This Document: 21 April, 2010 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: Desktop 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From john.fischer@oracle.com Wed Apr 21 08:49:17 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3LFnH08007399 for ; Wed, 21 Apr 2010 08:49:17 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3LFnCK6030283; Wed, 21 Apr 2010 09:49:15 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L18009IHHA2YY00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Apr 2010 08:49:15 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1800LJ6HA20ZD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Apr 2010 08:49:14 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3LFnDAi000097; Wed, 21 Apr 2010 15:49:13 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3L1ftmq013007; Wed, 21 Apr 2010 15:49:11 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt354.oracle.com with ESMTP id 178335171271864866; Wed, 21 Apr 2010 08:47:46 -0700 Received: from [10.7.250.1] (/10.7.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Apr 2010 08:47:46 -0700 Date: Wed, 21 Apr 2010 08:47:44 -0700 From: John Fischer Subject: PSARC/2010/138 - pkgbuild build engine To: PSARC-ext , "Laszlo (Laca) Peter" Message-id: <4BCF1E20.7030507@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_qrJHEJbGdYFotAt13S11NA)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BCF1E78.0095:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 8746 This is a multi-part message in MIME format. --Boundary_(ID_qrJHEJbGdYFotAt13S11NA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT All, I am sponsoring this case for Laszlo (Laca) Peter of the desktop group. I have set the timeout for Wednesday, April 21st, 2010. The case directory contains this proposal. This case proposes to integrate pkgbuild into a Minor release of Solaris. pkgbuild is the build engine developed by the desktop release engineering team to build the desktop components. It is similar to rpmbuild for linux. Thanks, John --Boundary_(ID_qrJHEJbGdYFotAt13S11NA) Content-type: text/plain; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=proposal.txt Title: pkgbuild build engine Case: PSARC/2010/138 Submitter: Laszlo (Laca) Peter Owner: John Fischer Timeout: 04/28/2010 1.0 Introduction 1.1 Project/Component Working Name: pkgbuild build engine 1.2 Purpose This project delivers the pkgbuild build engine into OpenSolaris. Minor release binding is requested. 2.0 Summary Description pkgbuild is a build engine developed by the Desktop Release Engineering team. It has been used for building the Desktop components of Solaris/ OpenSolaris since 2004. It is also used for building the OpenSolaris /contrib package repository. 2.1 Detailed Description The original purpose of pkgbuild was to facilitate delivering identical code using very similar build procedures on an RPM-based Linux system (JDS) and on Solaris. For this reason, the input of pkgbuild is a spec file[1] similar to RPM's. pkgbuild also has the same CLI and the same output format as rpmbuild, making it familiar to developers who have a background in Linux/RPM packaging. A complete pkgbuild build of a component consists of the following steps (corresponding spec file sections in parentheses): o set up source tree (%prep section) - unpack sources - apply source changes/patches o configure and compile the sources (%build) o install the binaries to a temporary proto area (%install) o generate package prototypes / manifests and create / publish packages All of the above steps are identical to rpmbuild's behaviour, the difference is the end result, which is a source RPM and one or more binary RPMs in the case of rpmbuild, and a source package and one or more binary packages (SVr4 and/or IPS) in the case of pkgbuild. The spec file includes all metainformation required for the above steps, including the location of the sources (a URL), patch names, build-time and runtime dependencies, IPS tags, attributes, actions. pkgbuild builds a single component at a time. It looks for sources (source bundles, individual files, patches and copyright files) in %_topdir/SOURCES. (%_topdir is macro that defines the location of the root of the build area). Additional spec files that may be used included using %include or %use statements must be located in %_topdir/SPECS. The build is performed in a subdirectory under the %_topdir/BUILD directory. Dynamically created SVr4 prototype, pkginfo, depend files, package scripts (e.g. CAS or postinstall) and IPS manifest files are created under %_topdir/PKGMAPS. SVr4 packages are created in %_topdir/PKGS and SVr4 "source packages" under %_topdir/SPKGS. Source packages include all files required for reproducing the build (specs, sources bundles, patches, etc). pkgbuild can automatically rebuild source packages using pkgbuild --rebuild /path/to/source_package IPS packages are published in the repository specified by the PKGBUILD_IPS_SERVER environment variable, or the local repository, if running (as determined using smf commands). Source IPS packages are published in $PKGBUILD_SRC_IPS_SERVER or PKGBUILD_IPS_SERVER or the local IPS repository. At this time, pkgbuild is not able to automatically rebuild IPS source packages, however, it is possible to install the source package (will get installed under /usr/share/src) and then rebuild the package using pkgbuild --rebuild /usr/share/src/ A higher level build script, pkgtool is provided for various convenience functions: o download sources o locate previously downloaded sources and copy them to where pkgbuild expects them o build/install a number of spec files in the order determined by the dependency information in the given spec files o collect log files o send emails about build failures o compile build reports The spec files used by pkgbuild and RPM are not fully compatible because pkgbuild needs to accommodate for the differences. These differences are documented on the pkgbuild web site[2]. Full spec file documentation is not provided, because there is already a wealth of information available for rpm spec files. spectool is a command line utility intended for parsing spec files and querying information from that for the purpose of scripting or embedding the pkgbuild utilities in larger systems. spectool's functions include: o evaluating macros in the context of a spec file o print the IPS or SVr4 package names defined by a spec file o print build-time or runtime dependencies o print the list of sources used for the build o translate an SVr4 package name or file name to an IPS package name pkgbuild comes with a set of predefined macros. These are macros commonly available in RPM implementations (different distributions define different sets of macros). Additional macros can be defined in the spec files and include files, the command line (--define option) and the ~/.pkgbuildmacros file. This corresponds to RPM's ~/.rpmmacros file and the syntax of the files is the same. The most common use of this file is to define an alternative build area from the default ~/packages directory. The syntax for this is: %_topdir /path/to/build/area pkgtool's configuration file is ~/.pkgtoolrc. In addition, a .pkgtoolrc file in the current directory is also read. The order is ./pkgtoolrc, ~/.pkgtoolrc. A self-documenting template for this file can be generated using pkgtool --dumprc. 3.0 Delivery The proposed IPS package name is "command/build/pkgbuild". Should it be delivered to Solaris 10, the proposed SVr4 package name is SUNWpkgbuild. Both names Committed. 4.0 Interface classification +-----------------------------------------------------------------------+ | Interfaces Exported | +------------------------------+-----------------+----------------------+ | Interface Name | Classification | Comment | +------------------------------+-----------------+----------------------+ | /usr/bin/pkgbuild | Volatile | | | /usr/bin/pkgtool | Volatile | | | /usr/bin/spectool | Volatile | | | /usr/lib/pkgbuild-1.3.102 | Project Private | | | ~/.pkgbuildmacros | Uncommitted | user-defined macros | | ~/.pkgtoolrc | Uncommitted | configuration file | | ~/packages | Uncommitted | personal build area | | PKGBUILD_IPS_SERVER | Uncommitted | environment variable | | PKGBUILD_SRC_IPS_SERVER | Uncommitted | environment variable | +------------------------------+-----------------+----------------------+ +-----------------------------------------------------------------------+ | Interfaces Imported | +------------------------------+------------------+---------------------+ | Interface Name | Classification | Comment | +------------------------------+------------------+---------------------+ | perl 5.8.4 | Evolving | PSARC 1999/192 | | /usr/bin/pkg | Uncommitted | PSARC 2008/190 | +------------------------------+------------------+---------------------+ 5.0 References [1] http://www.rpm.org/max-rpm/ch-rpm-inside.html http://jucr.opensolaris.org/help/spec_file [2] http://pkgbuild.sourceforge.net/ --Boundary_(ID_qrJHEJbGdYFotAt13S11NA)-- From ro@CeBiTec.Uni-Bielefeld.DE Thu Apr 22 02:10:34 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3M9AVCB022713 for ; Thu, 22 Apr 2010 02:10:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3M9AU9F027344; Thu, 22 Apr 2010 02:10:30 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1900641THIBE00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Apr 2010 02:10:30 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1900L4OTHGRU90@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Apr 2010 02:10:28 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3M97xRK026120; Thu, 22 Apr 2010 09:10:28 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay42i.sun.com with ESMTP id BT-MMP-131847; Thu, 22 Apr 2010 09:10:21 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-102309498; Thu, 22 Apr 2010 09:10:20 +0000 (Z) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([129.70.160.84] [129.70.160.84]) by relay4i.sun.com with ESMTP id BT-MMP-4281199; Thu, 22 Apr 2010 09:10:19 +0000 (Z) Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 871F05E7; Thu, 22 Apr 2010 11:10:18 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wmBXGi3Ndgd5; Thu, 22 Apr 2010 11:10:17 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 389E95E6; Thu, 22 Apr 2010 11:10:17 +0200 (CEST) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.3+Sun/8.14.3/Submit) id o3M9AGHl004726; Thu, 22 Apr 2010 11:10:16 +0200 (MEST) Date: Thu, 22 Apr 2010 11:10:16 +0200 From: Rainer Orth Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BCF1E20.7030507@oracle.com> To: John Fischer Cc: PSARC-ext , "Laszlo (Laca) Peter" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: amavisd-new at cebitec.uni-bielefeld.de X-Antispam: No, score=0.0/5.0, scanned in 1.255sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BCF1E20.7030507@oracle.com> X-Authentication-warning: manam.CeBiTec.Uni-Bielefeld.DE: ro set sender to ro@CeBiTec.Uni-Bielefeld.DE using -f User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) Status: RO Content-Length: 1385 John Fischer writes: > 4.0 Interface classification > > +-----------------------------------------------------------------------+ > | Interfaces Exported | > +------------------------------+-----------------+----------------------+ > | Interface Name | Classification | Comment | > +------------------------------+-----------------+----------------------+ > | /usr/bin/pkgbuild | Volatile | | > | /usr/bin/pkgtool | Volatile | | > | /usr/bin/spectool | Volatile | | Is it really appropriate (and match reality) to make such a central piece of the JDS and contrib/SourceJucer build environments only Volatile? Uncommitted seems much more useful (unless the command really changes regularly in incompatible ways). > | /usr/lib/pkgbuild-1.3.102 | Project Private | | Why the versioning here? Is there any intention to deliver several versions in parallel? And do binaries live in there? Otherwise, /usr/share/pkgbuild might be more appropriate. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From laszlo.peter@oracle.com Thu Apr 22 02:26:47 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3M9Ql4I022852 for ; Thu, 22 Apr 2010 02:26:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3M9QiYm052821 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Apr 2010 03:26:47 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L190011RU8MZD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Apr 2010 02:26:46 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1900M7AU8M0E30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Apr 2010 02:26:46 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3M9Qjvp001714 for ; Thu, 22 Apr 2010 09:26:45 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3M400fT005932; Thu, 22 Apr 2010 09:26:41 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 180524941271928286; Thu, 22 Apr 2010 02:24:46 -0700 Received: from [192.168.1.100] (/60.234.234.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Apr 2010 02:24:46 -0700 Date: Thu, 22 Apr 2010 21:24:38 +1200 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: To: Rainer Orth Cc: John Fischer , PSARC-ext Message-id: <1271928278.21971.9.camel@tecra> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0202.4BD01652.0039:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> Status: RO Content-Length: 1599 On Thu, 2010-04-22 at 11:10 +0200, Rainer Orth wrote: > John Fischer writes: > > > 4.0 Interface classification > > > > +-----------------------------------------------------------------------+ > > | Interfaces Exported | > > +------------------------------+-----------------+----------------------+ > > | Interface Name | Classification | Comment | > > +------------------------------+-----------------+----------------------+ > > | /usr/bin/pkgbuild | Volatile | | > > | /usr/bin/pkgtool | Volatile | | > > | /usr/bin/spectool | Volatile | | > > Is it really appropriate (and match reality) to make such a central > piece of the JDS and contrib/SourceJucer build environments only > Volatile? Uncommitted seems much more useful (unless the command really > changes regularly in incompatible ways). I have no objection to upgrading to Uncommitted. > > | /usr/lib/pkgbuild-1.3.102 | Project Private | | > > Why the versioning here? Is there any intention to deliver several > versions in parallel? And do binaries live in there? Otherwise, > /usr/share/pkgbuild might be more appropriate. We had situations in the past when installing 2 versions in parallel was desirable. There is no intention to deliver 2 versions, though. The directory contains 1 binary, the rest could live under /usr/share. Laca From scott.rotondo@oracle.com Fri Apr 23 17:19:30 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3O0JUOB012818 for ; Fri, 23 Apr 2010 17:19:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3O0JSEp052884; Fri, 23 Apr 2010 18:19:28 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1C00307U8GJH00@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Apr 2010 17:19:28 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1C0018DU8F7C20@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Apr 2010 17:19:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3O0JR4f024032; Sat, 24 Apr 2010 00:19:27 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3O0JQT9017102; Sat, 24 Apr 2010 00:19:26 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 185754691272068352; Fri, 23 Apr 2010 17:19:12 -0700 Received: from [129.146.108.62] (/129.146.108.62) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Apr 2010 17:19:12 -0700 Date: Fri, 23 Apr 2010 17:19:16 -0700 From: Scott Rotondo Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BCF1E20.7030507@oracle.com> To: PSARC-ext Cc: John Fischer , "Laszlo (Laca) Peter" Message-id: <4BD23904.2000004@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BD2390F.0028:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 891 John Fischer wrote: > All, > > I am sponsoring this case for Laszlo (Laca) Peter of the desktop group. > I have set the timeout for Wednesday, April 21st, 2010. The case directory > contains this proposal. > > This case proposes to integrate pkgbuild into a Minor release of Solaris. > pkgbuild is the build engine developed by the desktop release engineering > team to build the desktop components. It is similar to rpmbuild for linux. > Until now, the "pkg" prefix has generally been used for commands that are part of either the SVR4 or IPS packaging systems. I'm wondering if it's a good idea to introduce two utilities, pkgbuild and pkgtool, that use this naming convention but are not (primarily) packaging tools. Scott -- Scott Rotondo Senior Principal Engineer, Solaris Core OS Engineering President, Trusted Computing Group Phone/FAX: +1 650 786 6309 (Internal x86309) From laszlo.peter@oracle.com Sun Apr 25 03:16:07 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3PAG7Zi023589 for ; Sun, 25 Apr 2010 03:16:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3PAG7qT013794 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 25 Apr 2010 03:16:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1F00401GIV3300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 25 Apr 2010 04:16:07 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1F00FJOGIUH8B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 25 Apr 2010 04:16:06 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3PAG5h2016121 for ; Sun, 25 Apr 2010 10:16:06 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3P9vIPo023541 for ; Sun, 25 Apr 2010 10:16:05 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 206169221272190473; Sun, 25 Apr 2010 03:14:33 -0700 Received: from [192.168.1.100] (/60.234.234.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 25 Apr 2010 03:14:32 -0700 Date: Sun, 25 Apr 2010 22:14:21 +1200 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BD23904.2000004@oracle.com> To: Scott Rotondo Cc: PSARC-ext , John Fischer Message-id: <1272190461.4806.40.camel@tecra> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BD41665.010E:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BD23904.2000004@oracle.com> Status: RO Content-Length: 1107 On Fri, 2010-04-23 at 17:19 -0700, Scott Rotondo wrote: > John Fischer wrote: > > This case proposes to integrate pkgbuild into a Minor release of Solaris. > > pkgbuild is the build engine developed by the desktop release engineering > > team to build the desktop components. It is similar to rpmbuild for linux. > > > > Until now, the "pkg" prefix has generally been used for commands that > are part of either the SVR4 or IPS packaging systems. I'm wondering if > it's a good idea to introduce two utilities, pkgbuild and pkgtool, that > use this naming convention but are not (primarily) packaging tools. The idea behind the naming was that pkgbuild mimics rpmbuild, except that it creates SVr4 (and more recently pkg(5)) packages and not RPMs. So, although not part of those packaging tools, it's closely related. Also, this name has been in use for 6 years now and it's fairly well known. The first google hit for pkgbuild is this pkgbuild. It appears in many blog entries, build instructions, mailing list discussions, conference papers. Renaming it would cause a lot of confusion. Laca From carlsonj@workingcode.com Sun Apr 25 09:41:55 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3PGfsFM026883 for ; Sun, 25 Apr 2010 09:41:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3PGfrFn021104 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 25 Apr 2010 11:41:54 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1F00J01YDUW900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 25 Apr 2010 09:41:54 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1F00GDHYDTCPC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 25 Apr 2010 09:41:53 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3PGfq4c011182 for ; Sun, 25 Apr 2010 16:41:53 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-4793262 for PSARC-ext@sun.com; Sun, 25 Apr 2010 16:41:52 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-158131006 for PSARC-ext@sun.com; Sun, 25 Apr 2010 16:41:52 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-12096692 for PSARC-ext@sun.com; Sun, 25 Apr 2010 16:41:52 +0000 (Z) Received: from [192.168.254.211] (dhcp-211 [192.168.254.211]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o3PGfk8S010028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Apr 2010 12:41:48 -0400 (EDT) Date: Sun, 25 Apr 2010 12:41:44 -0400 From: James Carlson Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <1272190461.4806.40.camel@tecra> To: "Laszlo (Laca) Peter" Cc: Scott Rotondo , PSARC-ext Message-id: <4BD470C8.8020901@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-x.dcc-servers-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.177sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BCF1E20.7030507@oracle.com> <4BD23904.2000004@oracle.com> <1272190461.4806.40.camel@tecra> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Status: RO Content-Length: 785 On 4/25/2010 6:14 AM, Laszlo (Laca) Peter wrote: > Also, this name has been in use for 6 years now and it's fairly well > known. The first google hit for pkgbuild is this pkgbuild. It appears > in many blog entries, build instructions, mailing list discussions, > conference papers. Renaming it would cause a lot of confusion. Indeed; it would be difficult at this point to create an unconfused naming scheme for the IPS-related tools. The horse is too far out of the barn. But a point for the future: this is why the ARC has always requested that project teams visit the ARC "early and often," so that high-level system-wide consistency issues can be addressed before they turn into a fait accompli. -- James Carlson 42.703N 71.076W From sebastien.roy@oracle.com Fri Apr 30 12:30:54 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3UJUsui026345 for ; Fri, 30 Apr 2010 12:30:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3UJUqLh014401; Fri, 30 Apr 2010 12:30:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1P00F01FJGP500@nwk-avmta-2.sfbay.sun.com>; Fri, 30 Apr 2010 12:30:52 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1P0018YFJGVWF0@nwk-avmta-2.sfbay.sun.com>; Fri, 30 Apr 2010 12:30:52 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3UJUplY013042; Fri, 30 Apr 2010 19:30:52 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3UGLlrI001483; Fri, 30 Apr 2010 19:30:51 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 225980331272655774; Fri, 30 Apr 2010 12:29:34 -0700 Received: from [129.148.19.4] (/129.148.19.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Apr 2010 12:29:34 -0700 Date: Fri, 30 Apr 2010 15:29:31 -0400 From: Sebastien Roy Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BCF1E20.7030507@oracle.com> To: John Fischer Cc: PSARC-ext , "Laszlo (Laca) Peter" Message-id: <4BDB2F9B.5010405@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BDB2FEB.009B:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 531 A couple of minor questions: The spec file syntax is also conceptually an exported interface, and it needs a stability level. It would be nice if the spec file syntax were part of the materials (I'm guessing it's documented somewhere anyway). How will the tools handle a hypothetical syntactic change in the spec file format? Is there versioning built-in to the format? What kinds of source URLs are supported (e.g., http://, https://, file://, ftp://, all of the above?)? Does this deal with HTTP proxies? How? -Seb From sebastien.roy@oracle.com Fri Apr 30 12:35:41 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3UJZft8026631 for ; Fri, 30 Apr 2010 12:35:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3UJZcNL028646; Fri, 30 Apr 2010 12:35:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1P00701FRG2G00@brm-avmta-1.central.sun.com>; Fri, 30 Apr 2010 13:35:40 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1P008AFFRFA8F0@brm-avmta-1.central.sun.com>; Fri, 30 Apr 2010 13:35:39 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3UJZdBQ017975; Fri, 30 Apr 2010 19:35:39 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3U40AoP006813; Fri, 30 Apr 2010 19:35:37 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt353.oracle.com with ESMTP id 205552631272656061; Fri, 30 Apr 2010 12:34:21 -0700 Received: from [129.148.19.4] (/129.148.19.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Apr 2010 12:34:20 -0700 Date: Fri, 30 Apr 2010 15:34:19 -0400 From: Sebastien Roy Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDB2F9B.5010405@oracle.com> To: John Fischer Cc: PSARC-ext , "Laszlo (Laca) Peter" Message-id: <4BDB30BB.9080806@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BDB310A.007A:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 688 On 04/30/10 03:29 PM, Sebastien Roy wrote: > A couple of minor questions: > > The spec file syntax is also conceptually an exported interface, and it > needs a stability level. It would be nice if the spec file syntax were > part of the materials (I'm guessing it's documented somewhere anyway). > > How will the tools handle a hypothetical syntactic change in the spec > file format? Is there versioning built-in to the format? > > What kinds of source URLs are supported (e.g., http://, https://, > file://, ftp://, all of the above?)? Does this deal with HTTP proxies? How? One more: Can a regular user with basic privileges use these commands to create and publish packages? -Seb From trisk@opensolaris.org Fri Apr 30 13:15:16 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3UKFG4u028283 for ; Fri, 30 Apr 2010 13:15:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3UKFFco008972 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 Apr 2010 14:15:16 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1P00I0FHLFKD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 Apr 2010 13:15:15 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1P00HCUHLFFP40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 Apr 2010 13:15:15 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3UKFEEI020944 for ; Fri, 30 Apr 2010 20:15:15 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay41i.sun.com with ESMTP id BT-MMP-613539 for PSARC-ext@sun.com; Fri, 30 Apr 2010 20:13:14 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-121150186 for PSARC-ext@sun.com; Fri, 30 Apr 2010 20:13:14 +0000 (Z) Received: from rcmdxob3.cavtel.net ([64.83.1.89] [64.83.1.89]) by relay4i.sun.com with ESMTP id BT-MMP-25404644 for PSARC-ext@sun.com; Fri, 30 Apr 2010 20:13:14 +0000 (Z) Received: from rcmdxob2.cavtel.net (unknown [192.168.247.87]) by rcmdxob3.cavtel.net (Postfix) with ESMTP id 42F5E63D026 for ; Fri, 30 Apr 2010 16:13:14 -0400 (EDT) Received: from mail.deadgerbil.com (static-98-140-245-86.dsl.cavtel.net [98.140.245.86]) by rcmdxob2.cavtel.net (Postfix) with ESMTP id 2880D33C10B for ; Fri, 30 Apr 2010 16:10:39 -0400 (EDT) Received: from DSPAM (localhost [127.0.0.1]) by mail.deadgerbil.com (Postfix) with SMTP id 810372B42 for ; Fri, 30 Apr 2010 16:04:51 -0400 (EDT) Received: from mail.deadgerbil.com (localhost [127.0.0.1]) by mail.deadgerbil.com (Postfix) with ESMTP id BAFE32B3E; Fri, 30 Apr 2010 16:04:50 -0400 (EDT) Date: Fri, 30 Apr 2010 16:04:50 -0400 From: Albert Lee Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDB30BB.9080806@oracle.com> X-Sender: trisk@opensolaris.org To: Sebastien Roy Cc: John Fischer , PSARC-ext , "Laszlo (Laca) Peter" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Apr 30 16:04:51 2010 X-DSPAM-Confidence: 0.9979 X-DSPAM-Probability: -1.0000 X-DSPAM-Signature: 4bdb37e33861817126539 X-Antispam: No, score=-0.7/5.0, scanned in 0.066sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> User-Agent: RoundCube Webmail/0.3-trunk Status: RO Content-Length: 1469 On Fri, 30 Apr 2010 15:34:19 -0400, Sebastien Roy wrote: > On 04/30/10 03:29 PM, Sebastien Roy wrote: >> A couple of minor questions: >> >> The spec file syntax is also conceptually an exported interface, and it >> needs a stability level. It would be nice if the spec file syntax were >> part of the materials (I'm guessing it's documented somewhere anyway). >> The basic syntax is the same as rpmbuild spec files, and pkgbuild includes a set of predefined macros and supports some additional tags (attributes/keywords): http://pkgbuild.sourceforge.net/man.php >> How will the tools handle a hypothetical syntactic change in the spec >> file format? Is there versioning built-in to the format? >> I don't believe a versioning mechanism exists, but one could be constructed based on tags or macros. >> What kinds of source URLs are supported (e.g., http://, https://, >> file://, ftp://, all of the above?)? Does this deal with HTTP proxies? >> How? pkgtool invokes external wget for missing sources, so this is probably specified by wget. > > One more: > > Can a regular user with basic privileges use these commands to create > and publish packages? > pkgbuild doesn't need additional privileges to create SVR4 packages or use pkgsend (where restrictions would be dependent on the server). pkgtool is also aware of how to invoke pkgadd for SVR4 packages, and for that pkgadd assumes the "Software Installation" profile. -Albert From sebastien.roy@oracle.com Fri Apr 30 14:31:52 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3ULVqFX029292 for ; Fri, 30 Apr 2010 14:31:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3ULVoc6022092; Fri, 30 Apr 2010 14:31:51 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1P00J0BL528P00@brm-avmta-1.central.sun.com>; Fri, 30 Apr 2010 15:31:50 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1P007W7L52Z3C0@brm-avmta-1.central.sun.com>; Fri, 30 Apr 2010 15:31:50 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3ULVn3H006466; Fri, 30 Apr 2010 21:31:50 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3UKZar9016519; Fri, 30 Apr 2010 21:31:46 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 226297051272663106; Fri, 30 Apr 2010 14:31:46 -0700 Received: from [129.148.19.4] (/129.148.19.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Apr 2010 14:31:45 -0700 Date: Fri, 30 Apr 2010 17:31:44 -0400 From: Sebastien Roy Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: To: Albert Lee Cc: John Fischer , PSARC-ext , "Laszlo (Laca) Peter" Message-id: <4BDB4C40.4010100@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BDB4C42.0165:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2022 On 04/30/10 04:04 PM, Albert Lee wrote: > On Fri, 30 Apr 2010 15:34:19 -0400, Sebastien Roy > wrote: >> On 04/30/10 03:29 PM, Sebastien Roy wrote: >>> A couple of minor questions: >>> >>> The spec file syntax is also conceptually an exported interface, and it >>> needs a stability level. It would be nice if the spec file syntax were >>> part of the materials (I'm guessing it's documented somewhere anyway). >>> > > The basic syntax is the same as rpmbuild spec files, and pkgbuild includes > a set of predefined macros and supports some additional tags > (attributes/keywords): http://pkgbuild.sourceforge.net/man.php The initial request in my original comment was for the stability level of the spec file syntax. I would guess that it's relatively stable since you mention below that it has no concept of versioning, and presumably the format has been used for rpm's for Linux for a very long time. Is it Committed, Uncommitted, ...? >>> How will the tools handle a hypothetical syntactic change in the spec >>> file format? Is there versioning built-in to the format? >>> > > I don't believe a versioning mechanism exists, but one could be > constructed based on tags or macros. So the absence of such a hypothetical future tag or macro would indicate an older version. >>> What kinds of source URLs are supported (e.g., http://, https://, >>> file://, ftp://, all of the above?)? Does this deal with HTTP proxies? >>> How? > > pkgtool invokes external wget for missing sources, so this is probably > specified by wget. That answers the question, yes. >> >> One more: >> >> Can a regular user with basic privileges use these commands to create >> and publish packages? >> > > pkgbuild doesn't need additional privileges to create SVR4 packages or use > pkgsend (where restrictions would be dependent on the server). > pkgtool is also aware of how to invoke pkgadd for SVR4 packages, and for > that pkgadd assumes the "Software Installation" profile. Excellent, thanks. -Seb From trisk@opensolaris.org Fri Apr 30 17:54:06 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o410s5bS003368 for ; Fri, 30 Apr 2010 17:54:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o410s4x3024145 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 Apr 2010 17:54:05 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1P00805UI5QA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 30 Apr 2010 17:54:05 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1P006LPUI4LX20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 30 Apr 2010 17:54:04 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o410s3tA008044 for ; Sat, 01 May 2010 00:54:04 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-622776 for PSARC-ext@Sun.COM; Sat, 01 May 2010 00:54:03 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-121371907 for PSARC-ext@Sun.COM; Sat, 01 May 2010 00:54:03 +0000 (Z) Received: from rcmdxob3.cavtel.net ([64.83.1.89] [64.83.1.89]) by relay4i.sun.com with ESMTP id BT-MMP-22723814 for PSARC-ext@Sun.COM; Sat, 01 May 2010 00:54:03 +0000 (Z) Received: from rcmdxob2.cavtel.net (unknown [192.168.247.87]) by rcmdxob3.cavtel.net (Postfix) with ESMTP id ECC2663C448 for ; Fri, 30 Apr 2010 20:54:02 -0400 (EDT) Received: from mail.deadgerbil.com (static-98-140-245-86.dsl.cavtel.net [98.140.245.86]) by rcmdxob2.cavtel.net (Postfix) with ESMTP id B6E2433C08B for ; Fri, 30 Apr 2010 20:48:59 -0400 (EDT) Received: from DSPAM (localhost [127.0.0.1]) by mail.deadgerbil.com (Postfix) with SMTP id 938E62E03 for ; Fri, 30 Apr 2010 20:48:58 -0400 (EDT) Received: from mail.deadgerbil.com (localhost [127.0.0.1]) by mail.deadgerbil.com (Postfix) with ESMTP id 111D22DFF; Fri, 30 Apr 2010 20:48:58 -0400 (EDT) Date: Fri, 30 Apr 2010 20:48:57 -0400 From: Albert Lee Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDB4C40.4010100@oracle.com> X-Sender: trisk@opensolaris.org To: Sebastien Roy Cc: John Fischer , PSARC-ext , "Laszlo (Laca) Peter" Message-id: <6f14ee3222731a640e90675cdcca223b@quasarnet.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Apr 30 20:48:58 2010 X-DSPAM-Confidence: 0.9987 X-DSPAM-Probability: -1.0000 X-DSPAM-Signature: 4bdb7a7a3862428018584 X-Antispam: No, score=-1.1/5.0, scanned in 0.168sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDB4C40.4010100@oracle.com> User-Agent: RoundCube Webmail/0.3-trunk Status: RO Content-Length: 2280 On Fri, 30 Apr 2010 17:31:44 -0400, Sebastien Roy wrote: > On 04/30/10 04:04 PM, Albert Lee wrote: >> On Fri, 30 Apr 2010 15:34:19 -0400, Sebastien Roy >> wrote: >>> On 04/30/10 03:29 PM, Sebastien Roy wrote: >>>> A couple of minor questions: >>>> >>>> The spec file syntax is also conceptually an exported interface, and it >>>> needs a stability level. It would be nice if the spec file syntax were >>>> part of the materials (I'm guessing it's documented somewhere anyway). >>>> >> >> The basic syntax is the same as rpmbuild spec files, and pkgbuild >> includes >> a set of predefined macros and supports some additional tags >> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php > > The initial request in my original comment was for the stability level > of the spec file syntax. I would guess that it's relatively stable > since you mention below that it has no concept of versioning, and > presumably the format has been used for rpm's for Linux for a very long > time. Is it Committed, Uncommitted, ...? > I have to defer to laca on this one since it's his case. Uncommitted is probably not unreasonable since packages are already forced to stay in lock-step with external changes anyway. >>>> How will the tools handle a hypothetical syntactic change in the spec >>>> file format? Is there versioning built-in to the format? >>>> >> >> I don't believe a versioning mechanism exists, but one could be >> constructed based on tags or macros. > > So the absence of such a hypothetical future tag or macro would indicate > an older version. > That was what I had in mind. >>>> What kinds of source URLs are supported (e.g., http://, https://, >>>> file://, ftp://, all of the above?)? Does this deal with HTTP proxies? >>>> How? >> >> pkgtool invokes external wget for missing sources, so this is probably >> specified by wget. > > That answers the question, yes. > It occurs to me that the command line for pkgsend and wget (and possibly pkgadd) should be in the list of imported interfaces. pkg wget was left Volatile by PSARC/2007/681 (http://arc.opensolaris.org/caselog/PSARC/2007/681/mail has the discussion). PSARC/2008/190 didn't seem to specify a commitment for pkgsend? -Albert From laszlo.peter@oracle.com Sat May 1 05:15:15 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o41CFFtq000736 for ; Sat, 1 May 2010 05:15:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o41CFEYn050840 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 1 May 2010 06:15:14 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Q00A03Q1EPZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 01 May 2010 05:15:14 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Q00MNUQ1DB2A0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 01 May 2010 05:15:13 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o41CFCeU029706 for ; Sat, 01 May 2010 12:15:13 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o41BOw4D001994; Sat, 01 May 2010 12:15:10 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 227263321272716105; Sat, 01 May 2010 05:15:05 -0700 Received: from [192.168.1.100] (/60.234.234.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 01 May 2010 05:15:04 -0700 Date: Sun, 02 May 2010 00:14:57 +1200 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <6f14ee3222731a640e90675cdcca223b@quasarnet.org> To: Albert Lee Cc: Sebastien Roy , John Fischer , PSARC-ext Message-id: <1272716097.5999.2.camel@tecra> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BDC1B4F.0055:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDB4C40.4010100@oracle.com> <6f14ee3222731a640e90675cdcca223b@quasarnet.org> Status: RO Content-Length: 712 Thanks Albert for answering the questions for me :) Agreed on all counts. On Fri, 2010-04-30 at 20:48 -0400, Albert Lee wrote: > > > The initial request in my original comment was for the stability level > > of the spec file syntax. I would guess that it's relatively stable > > since you mention below that it has no concept of versioning, and > > presumably the format has been used for rpm's for Linux for a very long > > time. Is it Committed, Uncommitted, ...? > > > > I have to defer to laca on this one since it's his case. Uncommitted is > probably not unreasonable since packages are already forced to stay in > lock-step with external changes anyway. Uncommitted sounds good to me. Laca From brian.cameron@oracle.com Sat May 1 05:54:45 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o41CsjZ1001067 for ; Sat, 1 May 2010 05:54:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o41Cshkh016143; Sat, 1 May 2010 05:54:43 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Q00001RV7U600@brm-avmta-1.central.sun.com>; Sat, 01 May 2010 06:54:43 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Q00N16RV619F0@brm-avmta-1.central.sun.com>; Sat, 01 May 2010 06:54:42 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o41CsgSx001897; Sat, 01 May 2010 12:54:42 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o41BOw1R022448; Sat, 01 May 2010 12:54:40 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 227306181272718474; Sat, 01 May 2010 05:54:34 -0700 Received: from [10.0.0.12] (/209.33.56.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 01 May 2010 00:16:53 -0700 Date: Sat, 01 May 2010 02:16:53 -0500 From: Brian Cameron Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: To: Albert Lee Cc: Sebastien Roy , John Fischer , PSARC-ext , "Laszlo (Laca) Peter" Message-id: <4BDBD565.3080004@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BDC2490.0124:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100427 Thunderbird/3.0.4 Status: RO Content-Length: 1011 Albert: >>> The spec file syntax is also conceptually an exported interface, and it >>> needs a stability level. It would be nice if the spec file syntax were >>> part of the materials (I'm guessing it's documented somewhere anyway). > > The basic syntax is the same as rpmbuild spec files, and pkgbuild includes > a set of predefined macros and supports some additional tags > (attributes/keywords): http://pkgbuild.sourceforge.net/man.php True, although pkgbuild does support some Solaris/OpenSolaris specific extensions, and it might be good to highlight those a bit more. For example, one thing I notice is that the new "IPS_package_name" and "Meta(info.classification)" keys cause syntax errors if you try to use an older version of pkgbuild. It would be nice if pkgbuild had better backwards compatibility support and provided some mechanism to allow people who just want to build SVR5 packages a way to tell pkgbuild to ignore keys that provide features that are not going to be used anyway. Brian From trisk@opensolaris.org Sat May 1 10:11:16 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o41HBG44003455 for ; Sat, 1 May 2010 10:11:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o41HBGEw001304 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 1 May 2010 10:11:16 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1R008013QS1G00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 01 May 2010 11:11:16 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1R0016F3QRLH90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 01 May 2010 11:11:15 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o41HBFAY023255 for ; Sat, 01 May 2010 17:11:15 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-638317 for PSARC-ext@sun.com; Sat, 01 May 2010 17:11:15 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-175313616 for PSARC-ext@sun.com; Sat, 01 May 2010 17:11:15 +0000 (Z) Received: from rcmdxob3.cavtel.net ([64.83.1.89] [64.83.1.89]) by relay1i.sun.com with ESMTP id BT-MMP-29450947 for PSARC-ext@sun.com; Sat, 01 May 2010 17:11:14 +0000 (Z) Received: from rcmdxob2.cavtel.net (unknown [192.168.247.87]) by rcmdxob3.cavtel.net (Postfix) with ESMTP id 99C4A63C643 for ; Sat, 01 May 2010 13:11:13 -0400 (EDT) Received: from mail.deadgerbil.com (static-98-140-245-86.dsl.cavtel.net [98.140.245.86]) by rcmdxob2.cavtel.net (Postfix) with ESMTP id 672E833C07E for ; Sat, 01 May 2010 13:11:13 -0400 (EDT) Received: from DSPAM (localhost [127.0.0.1]) by mail.deadgerbil.com (Postfix) with SMTP id 6CC5526AD for ; Sat, 01 May 2010 13:11:12 -0400 (EDT) Received: from mail.deadgerbil.com (localhost [127.0.0.1]) by mail.deadgerbil.com (Postfix) with ESMTP id 74F3E26A3; Sat, 01 May 2010 13:11:11 -0400 (EDT) Date: Sat, 01 May 2010 13:11:11 -0400 From: Albert Lee Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDBD565.3080004@oracle.com> X-Sender: trisk@opensolaris.org To: Brian Cameron Cc: Sebastien Roy , John Fischer , PSARC-ext , "Laszlo (Laca) Peter" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat May 1 13:11:12 2010 X-DSPAM-Confidence: 0.9980 X-DSPAM-Probability: -1.0000 X-DSPAM-Signature: 4bdc60b03861256526772 X-Antispam: No, score=0.0/5.0, scanned in 0.098sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> User-Agent: RoundCube Webmail/0.3-trunk Status: RO Content-Length: 1317 On Sat, 01 May 2010 02:16:53 -0500, Brian Cameron wrote: > Albert: > >>>> The spec file syntax is also conceptually an exported interface, and it >>>> needs a stability level. It would be nice if the spec file syntax were >>>> part of the materials (I'm guessing it's documented somewhere anyway). >> >> The basic syntax is the same as rpmbuild spec files, and pkgbuild >> includes >> a set of predefined macros and supports some additional tags >> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php > > True, although pkgbuild does support some Solaris/OpenSolaris specific > extensions, and it might be good to highlight those a bit more. > > For example, one thing I notice is that the new "IPS_package_name" > and "Meta(info.classification)" keys cause syntax errors if you try > to use an older version of pkgbuild. It would be nice if pkgbuild > had better backwards compatibility support and provided some mechanism > to allow people who just want to build SVR5 packages a way to tell > pkgbuild to ignore keys that provide features that are not going to be > used anyway. > If it's desirable to keep older pkgbuild versions working with new spec files, it might be necessary to introduce macros for %if guards around new tags that are not being ignored. -Albert From laszlo.peter@oracle.com Sun May 2 03:00:33 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o42A0WJQ025088 for ; Sun, 2 May 2010 03:00:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o42A0WoI008231 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 2 May 2010 05:00:32 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1S00E0FEGWLU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 02 May 2010 03:00:32 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1S00MUVEGV2J20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 02 May 2010 03:00:31 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o42A0VN2004519 for ; Sun, 02 May 2010 10:00:31 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o429S0Xt031187; Sun, 02 May 2010 10:00:28 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 207619961272794366; Sun, 02 May 2010 02:59:26 -0700 Received: from [192.168.1.100] (/60.234.234.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 02 May 2010 02:59:25 -0700 Date: Sun, 02 May 2010 01:20:00 +1200 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDBD565.3080004@oracle.com> To: Brian Cameron Cc: Albert Lee , Sebastien Roy , John Fischer , PSARC-ext Message-id: <1272720000.6679.58.camel@tecra> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BDD4D3C.00AF:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> Status: RO Content-Length: 1095 Brian, On Sat, 2010-05-01 at 02:16 -0500, Brian Cameron wrote: > True, although pkgbuild does support some Solaris/OpenSolaris specific > extensions, and it might be good to highlight those a bit more. I agree that these need to be better documented. > For example, one thing I notice is that the new "IPS_package_name" > and "Meta(info.classification)" keys cause syntax errors if you try > to use an older version of pkgbuild. Compatibility of the spec file format is maintained in the opposite direction: your old spec files should work with new releases of pkgbuild. > It would be nice if pkgbuild > had better backwards compatibility support and provided some mechanism > to allow people who just want to build SVR5 packages a way to tell > pkgbuild to ignore keys that provide features that are not going to be > used anyway. While there have been many recent additions to support IPS, new features are not limited to those. Generally speaking, if you need to build spec files that make use of new features, you have to upgrade to a release that supports those features. Laca From sebastien.roy@oracle.com Mon May 3 08:40:48 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o43Fem86025469 for ; Mon, 3 May 2010 08:40:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o43FekZs013268; Mon, 3 May 2010 08:40:46 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1U00A09OVYRT00@brm-avmta-1.central.sun.com>; Mon, 03 May 2010 09:40:46 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1U00JJEOVX5YD0@brm-avmta-1.central.sun.com>; Mon, 03 May 2010 09:40:45 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o43FejEl018953; Mon, 03 May 2010 15:40:45 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o436tHF4031912; Mon, 03 May 2010 15:40:42 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 231371091272901232; Mon, 03 May 2010 08:40:32 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 May 2010 08:40:31 -0700 Date: Mon, 03 May 2010 11:40:30 -0400 From: Sebastien Roy Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <6f14ee3222731a640e90675cdcca223b@quasarnet.org> To: Albert Lee Cc: John Fischer , PSARC-ext , "Laszlo (Laca) Peter" Message-id: <4BDEEE6E.9010007@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BDEEE7B.00EB:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDB4C40.4010100@oracle.com> <6f14ee3222731a640e90675cdcca223b@quasarnet.org> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1466 On 04/30/10 08:48 PM, Albert Lee wrote: > On Fri, 30 Apr 2010 17:31:44 -0400, Sebastien Roy > wrote: >>>>> What kinds of source URLs are supported (e.g., http://, https://, >>>>> file://, ftp://, all of the above?)? Does this deal with HTTP > proxies? >>>>> How? >>> >>> pkgtool invokes external wget for missing sources, so this is probably >>> specified by wget. >> >> That answers the question, yes. >> > > It occurs to me that the command line for pkgsend and wget (and possibly > pkgadd) should be in the list of imported interfaces. pkg wget was left > Volatile by PSARC/2007/681 > (http://arc.opensolaris.org/caselog/PSARC/2007/681/mail has the > discussion). Agreed; they are imported interfaces. I think reality has caught up with wget's initial stability level of Volatile (as John Plocher states in 2007/681). I don't think there's much we can do about that here, as I don't think contracts for wget would be productive at all given that it has extensive embedded use elsewhere. > PSARC/2008/190 didn't seem to specify a commitment for > pkgsend? That can be fixed; the case has only undergone a pre-inception, and so it is to be expected that some pieces are still under-specified. I would assume that it could be no less than Uncommitted, as I believe the IPS project team fully expects that the command would be used by scripts. It indeed needs to be called out as an imported interface for this case. -Seb From sebastien.roy@oracle.com Mon May 3 08:57:12 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o43FvCqm026060 for ; Mon, 3 May 2010 08:57:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o43Fv7kv021303 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 May 2010 08:57:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1U00C0HPNBEW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 May 2010 09:57:11 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1U00JTNPNB5ZB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 May 2010 09:57:11 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o43FvAfD002928 for ; Mon, 03 May 2010 15:57:11 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o43Fv2iu029104; Mon, 03 May 2010 15:57:03 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 210099781272902201; Mon, 03 May 2010 08:56:41 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 May 2010 08:56:41 -0700 Date: Mon, 03 May 2010 11:56:40 -0400 From: Sebastien Roy Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <1272716097.5999.2.camel@tecra> To: "Laszlo (Laca) Peter" Cc: Albert Lee , John Fischer , PSARC-ext Message-id: <4BDEF238.3030003@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BDEF254.0042:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDB4C40.4010100@oracle.com> <6f14ee3222731a640e90675cdcca223b@quasarnet.org> <1272716097.5999.2.camel@tecra> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100329 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1195 On 05/ 1/10 08:14 AM, Laszlo (Laca) Peter wrote: > Thanks Albert for answering the questions for me :) > Agreed on all counts. > > On Fri, 2010-04-30 at 20:48 -0400, Albert Lee wrote: >> >>> The initial request in my original comment was for the stability level >>> of the spec file syntax. I would guess that it's relatively stable >>> since you mention below that it has no concept of versioning, and >>> presumably the format has been used for rpm's for Linux for a very long >>> time. Is it Committed, Uncommitted, ...? >>> >> >> I have to defer to laca on this one since it's his case. Uncommitted is >> probably not unreasonable since packages are already forced to stay in >> lock-step with external changes anyway. > > Uncommitted sounds good to me. Okay. As I hinted in a prior message, I'm not entirely comfortable with a case exporting an Uncommitted interface without including its specification it in the case materials. If you can include at least the portions that are specific to Solaris as part of the materials (with the knowlege that the remainder is externally specified by Linux RPM) to nail down what the case is actually delivering, that would be welcome. -Seb From doug.leavitt@oracle.com Mon May 3 09:54:08 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o43Gs7mS026896 for ; Mon, 3 May 2010 09:54:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o43Gs5jB004787; Mon, 3 May 2010 09:54:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1U00I0JSA5B500@brm-avmta-1.central.sun.com>; Mon, 03 May 2010 10:54:05 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1U00E72SA5SE30@brm-avmta-1.central.sun.com>; Mon, 03 May 2010 10:54:05 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o43Gs48f012960; Mon, 03 May 2010 16:54:05 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o43Gruqm002114; Mon, 03 May 2010 16:53:56 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 231615601272905591; Mon, 03 May 2010 09:53:11 -0700 Received: from [10.7.251.243] (/10.7.251.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 May 2010 09:53:10 -0700 Date: Mon, 03 May 2010 11:53:07 -0500 From: Doug Leavitt Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDBD565.3080004@oracle.com> To: "Laszlo (Laca) Peter" Cc: Brian Cameron , Albert Lee , Sebastien Roy , John Fischer , PSARC-ext Message-id: <4BDEFF73.5030404@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BDEFFA8.003E:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Thunderbird/3.0.1 Status: RO Content-Length: 1860 In addition to the missing definitions for the Meta(*.*), SUNW*, and IPS* keys commonly deployed in pkgbuils spec files today, I also noticed that neither the proposal or the case materials make any reference to %include Solaris.inc or any of the include files Solaris.inc ifself includes and that are generally expected as part of current pkgbuild spec files, I believe that this ARC case needs to at least document and (hopefully) set some level of commitment to the well defined tag list. At a minimum this: http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/specdesc needs to be included in the ARC materials. But, I'm sure better documentation than above should be provided. Say perhaps a man page or two? Doug. On 05/ 1/10 02:16 AM, Brian Cameron wrote: > Albert: > > >>>> The spec file syntax is also conceptually an exported interface, and it >>>> needs a stability level. It would be nice if the spec file syntax were >>>> part of the materials (I'm guessing it's documented somewhere anyway). >>>> >> The basic syntax is the same as rpmbuild spec files, and pkgbuild includes >> a set of predefined macros and supports some additional tags >> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php >> > True, although pkgbuild does support some Solaris/OpenSolaris specific > extensions, and it might be good to highlight those a bit more. > > For example, one thing I notice is that the new "IPS_package_name" > and "Meta(info.classification)" keys cause syntax errors if you try > to use an older version of pkgbuild. It would be nice if pkgbuild > had better backwards compatibility support and provided some mechanism > to allow people who just want to build SVR5 packages a way to tell > pkgbuild to ignore keys that provide features that are not going to be > used anyway. > > Brian > > From laszlo.peter@oracle.com Mon May 3 16:36:29 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o43NaT5P006479 for ; Mon, 3 May 2010 16:36:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o43NaSw7011158 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 May 2010 18:36:28 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1V0030FAWSLN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 May 2010 16:36:28 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1V00CEAAWR6W80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 May 2010 16:36:27 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o43NaQUS026898 for ; Mon, 03 May 2010 23:36:27 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o43KwEI5020335; Mon, 03 May 2010 23:36:23 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 232888821272929687; Mon, 03 May 2010 16:34:47 -0700 Received: from [192.168.1.100] (/60.234.234.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 May 2010 16:34:46 -0700 Date: Tue, 04 May 2010 11:34:43 +1200 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDEF238.3030003@oracle.com> To: Sebastien Roy Cc: Albert Lee , John Fischer , PSARC-ext Message-id: <1272929683.13184.12.camel@tecra> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BDF5DF8.006E:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDB4C40.4010100@oracle.com> <6f14ee3222731a640e90675cdcca223b@quasarnet.org> <1272716097.5999.2.camel@tecra> <4BDEF238.3030003@oracle.com> Status: RO Content-Length: 639 On Mon, 2010-05-03 at 11:56 -0400, Sebastien Roy wrote: > Okay. As I hinted in a prior message, I'm not entirely comfortable with > a case exporting an Uncommitted interface without including its > specification it in the case materials. If you can include at least the > portions that are specific to Solaris as part of the materials (with the > knowlege that the remainder is externally specified by Linux RPM) to > nail down what the case is actually delivering, that would be welcome. Okay, I will write a document about the differences between RPM's and pkgbuild's spec file syntax and semantics and post it tomorrow. Laca From laszlo.peter@oracle.com Mon May 3 17:08:35 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4408ZjN007025 for ; Mon, 3 May 2010 17:08:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4408X1u001011 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 3 May 2010 17:08:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1V00G0LCEACA00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 03 May 2010 17:08:34 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1V00F6ACE8NL00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 03 May 2010 17:08:33 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4408W6q024401 for ; Tue, 04 May 2010 00:08:32 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o43MLCQ3006514; Tue, 04 May 2010 00:08:30 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt353.oracle.com with ESMTP id 211307871272931709; Mon, 03 May 2010 17:08:29 -0700 Received: from [192.168.1.100] (/60.234.234.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 May 2010 16:38:29 -0700 Date: Tue, 04 May 2010 11:38:25 +1200 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDEFF73.5030404@oracle.com> To: Doug Leavitt Cc: Brian Cameron , Albert Lee , Sebastien Roy , John Fischer , PSARC-ext Message-id: <1272929905.13184.16.camel@tecra> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BDF657E.00C2:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> Status: RO Content-Length: 2394 On Mon, 2010-05-03 at 11:53 -0500, Doug Leavitt wrote: > In addition to the missing definitions for the > Meta(*.*), SUNW*, and IPS* keys commonly deployed > in pkgbuils spec files today, I also noticed that neither > the proposal or the case materials make any reference to > > %include Solaris.inc > > or any of the include files Solaris.inc ifself includes and > that are generally expected as part of current pkgbuild > spec files, Solaris.inc and all the other include files are artifacts of the Desktop build environment that were replicated in other spec file-based build environments like Source Juicer and SFE. They ensure a level of consistency within the spec file repository / consolidation. pkgbuild itself does not require that you use them. > I believe that this ARC case needs to at least document > and (hopefully) set some level of commitment to the > well defined tag list. > > At a minimum this: > http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/specdesc > > needs to be included in the ARC materials. > > But, I'm sure better documentation than above > should be provided. Say perhaps a man page or two? Man pages will be provided for pkgbuild, pkgtool and spectool. Laca > On 05/ 1/10 02:16 AM, Brian Cameron wrote: > > Albert: > > > > > >>>> The spec file syntax is also conceptually an exported interface, and it > >>>> needs a stability level. It would be nice if the spec file syntax were > >>>> part of the materials (I'm guessing it's documented somewhere anyway). > >>>> > >> The basic syntax is the same as rpmbuild spec files, and pkgbuild includes > >> a set of predefined macros and supports some additional tags > >> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php > >> > > True, although pkgbuild does support some Solaris/OpenSolaris specific > > extensions, and it might be good to highlight those a bit more. > > > > For example, one thing I notice is that the new "IPS_package_name" > > and "Meta(info.classification)" keys cause syntax errors if you try > > to use an older version of pkgbuild. It would be nice if pkgbuild > > had better backwards compatibility support and provided some mechanism > > to allow people who just want to build SVR5 packages a way to tell > > pkgbuild to ignore keys that provide features that are not going to be > > used anyway. > > > > Brian > > > > From brian.cameron@oracle.com Tue May 4 09:58:39 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o44Gwdhu012360 for ; Tue, 4 May 2010 09:58:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o44Gwc4t001961 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 May 2010 09:58:38 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1W0080RN5QW900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 10:58:38 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1W003YVN5PT830@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 10:58:37 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o44Gwbbq018381 for ; Tue, 04 May 2010 16:58:37 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44Gimis031102; Tue, 04 May 2010 16:58:33 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 213557791272992307; Tue, 04 May 2010 09:58:27 -0700 Received: from [129.150.48.246] (/129.150.48.246) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 09:58:26 -0700 Date: Tue, 04 May 2010 11:58:28 -0500 From: Brian Cameron Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <1272929905.13184.16.camel@tecra> To: "Laszlo (Laca) Peter" Cc: Doug Leavitt , Albert Lee , Sebastien Roy , John Fischer , PSARC-ext Message-id: <4BE05234.1020200@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0204.4BE0523A.00C2:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <1272929905.13184.16.camel@tecra> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100427 Thunderbird/3.0.4 Status: RO Content-Length: 1301 Laca: >> or any of the include files Solaris.inc ifself includes and >> that are generally expected as part of current pkgbuild >> spec files, > > Solaris.inc and all the other include files are artifacts of > the Desktop build environment that were replicated in other > spec file-based build environments like Source Juicer and > SFE. They ensure a level of consistency within the spec file > repository / consolidation. pkgbuild itself does not require > that you use them. Whether or not they are interfaces and need documentation mainly depends on whether or not the include files are delivered with pkgbuild. If they are like Makefiles, and specific to particular repositories, then they are not interfaces provided with pkgbuild and need no ARC documentation. That said, it does seem like it might be useful to provide some default include files that provide some standard definitions that are expected to be used across repositories. Much like GNOME delivers some common Makefile include magic in the gnome-common module. Though this may not be something that makes sense for the initial pkgbuild delivery. It might be the case that the existing pkgbuild include files may need further refactoring to separate the truly project-independent definitions from ones that are not. Brian From laszlo.peter@oracle.com Tue May 4 18:03:45 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4513jge023412 for ; Tue, 4 May 2010 18:03:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4513hgc021854 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 May 2010 19:03:45 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1X00A019M81H00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 18:03:44 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1X00HRK9M8LI90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 18:03:44 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4513hm8017276 for ; Wed, 05 May 2010 01:03:43 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44JWQTO011438; Wed, 05 May 2010 01:03:41 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 237079711273021405; Tue, 04 May 2010 18:03:25 -0700 Received: from [192.168.1.100] (/60.234.234.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 18:03:24 -0700 Date: Wed, 05 May 2010 13:03:21 +1200 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BE05234.1020200@oracle.com> To: Brian Cameron Cc: Doug Leavitt , Albert Lee , Sebastien Roy , John Fischer , PSARC-ext Message-id: <1273021401.13184.49.camel@tecra> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE0C3ED.0115:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <1272929905.13184.16.camel@tecra> <4BE05234.1020200@oracle.com> Status: RO Content-Length: 1527 On Tue, 2010-05-04 at 11:58 -0500, Brian Cameron wrote: > Laca: > > >> or any of the include files Solaris.inc ifself includes and > >> that are generally expected as part of current pkgbuild > >> spec files, > > > > Solaris.inc and all the other include files are artifacts of > > the Desktop build environment that were replicated in other > > spec file-based build environments like Source Juicer and > > SFE. They ensure a level of consistency within the spec file > > repository / consolidation. pkgbuild itself does not require > > that you use them. > > Whether or not they are interfaces and need documentation mainly > depends on whether or not the include files are delivered with > pkgbuild. If they are like Makefiles, and specific to particular > repositories, then they are not interfaces provided with pkgbuild > and need no ARC documentation. They are not delivered with pkgbuild and yes, they are specific to the repositories they are used in. Although the basic structure is the same (due to being copies from one repo to the other), they need to be adjusted to the specific repo. > That said, it does seem like it might be useful to provide some > default include files that provide some standard definitions that > are expected to be used across repositories. Much like GNOME > delivers some common Makefile include magic in the gnome-common > module. Like you say, the GNOME project provides common Makefiles in gnome-common. GNU make does not come with useful standard Makefiles AFAIK. Laca From alan.coopersmith@oracle.com Tue May 4 18:12:13 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o451CCFE023469 for ; Tue, 4 May 2010 18:12:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o451CCwZ025249 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 May 2010 20:12:12 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1X00A03A0CLW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 18:12:12 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1X00HQRA0CLX90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 18:12:12 -0700 (PDT) Received: from [129.145.155.53] (sunray-osol-2.SFBay.Sun.COM [129.145.155.53]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o451CB7W025742; Tue, 04 May 2010 18:12:11 -0700 (PDT) Date: Tue, 04 May 2010 18:12:11 -0700 From: Alan Coopersmith Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <1273021401.13184.49.camel@tecra> To: "Laszlo (Laca) Peter" Cc: Brian Cameron , Doug Leavitt , Albert Lee , Sebastien Roy , John Fischer , PSARC-ext Message-id: <4BE0C5EB.80405@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <1272929905.13184.16.camel@tecra> <4BE05234.1020200@oracle.com> <1273021401.13184.49.camel@tecra> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 640 Laszlo (Laca) Peter wrote: > Like you say, the GNOME project provides common Makefiles in > gnome-common. GNU make does not come with useful standard > Makefiles AFAIK. GNU & Solaris make both come with makefile fragments included by default to define useful standard rules like .c.o: $(CC) -c $@ $< See /usr/share/lib/make/make.rules for Solaris make - I believe GNU make's are hardcoded in the gmake binary. Whether something similar makes sense for pkgbuild, either now or in a later case, is a different question. -- -Alan Coopersmith- alan.coopersmith@oracle.com Oracle Solaris Platform Engineering: X Window System From laszlo.peter@oracle.com Tue May 4 19:16:53 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o452GqFu024201 for ; Tue, 4 May 2010 19:16:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o452Gq3w029850 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 May 2010 19:16:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1X00601D043Z00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 19:16:52 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1X0099ED03N740@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 May 2010 19:16:52 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o452GpI6020730 for ; Wed, 05 May 2010 02:16:51 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4430ESX001924; Wed, 05 May 2010 02:16:48 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 214739781273025745; Tue, 04 May 2010 19:15:45 -0700 Received: from [192.168.1.100] (/60.234.234.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 19:15:44 -0700 Date: Wed, 05 May 2010 14:15:40 +1200 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BE0C5EB.80405@oracle.com> To: Alan Coopersmith Cc: Brian Cameron , Doug Leavitt , Albert Lee , Sebastien Roy , John Fischer , PSARC-ext Message-id: <1273025740.13184.58.camel@tecra> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE0D510.0119:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <1272929905.13184.16.camel@tecra> <4BE05234.1020200@oracle.com> <1273021401.13184.49.camel@tecra> <4BE0C5EB.80405@oracle.com> Status: RO Content-Length: 2029 On Tue, 2010-05-04 at 18:12 -0700, Alan Coopersmith wrote: > Laszlo (Laca) Peter wrote: > > Like you say, the GNOME project provides common Makefiles in > > gnome-common. GNU make does not come with useful standard > > Makefiles AFAIK. > > GNU & Solaris make both come with makefile fragments included > by default to define useful standard rules like > > .c.o: > $(CC) -c $@ $< > > See /usr/share/lib/make/make.rules for Solaris make - I believe > GNU make's are hardcoded in the gmake binary. > > Whether something similar makes sense for pkgbuild, either now > or in a later case, is a different question. I think the equivalent in pkgbuild would be the macros file (which was adopted from rpmbuild's macros file) that lives in $(libdir)/pkgbuild-$(version)/macros It includes some standard macro definitions like: %makeinstall \ make \\\ prefix=%{?buildroot:%{buildroot}}%{_prefix} \\\ exec_prefix=%{?buildroot:%{buildroot}}%{_exec_prefix} \\\ bindir=%{?buildroot:%{buildroot}}%{_bindir} \\\ sbindir=%{?buildroot:%{buildroot}}%{_sbindir} \\\ sysconfdir=%{?buildroot:%{buildroot}}%{_sysconfdir} \\\ datadir=%{?buildroot:%{buildroot}}%{_datadir} \\\ includedir=%{?buildroot:%{buildroot}}%{_includedir} \\\ libdir=%{?buildroot:%{buildroot}}%{_libdir} \\\ libexecdir=%{?buildroot:%{buildroot}}%{_libexecdir} \\\ localstatedir=%{?buildroot:%{buildroot}}%{_localstatedir} \\\ sharedstatedir=%{?buildroot:%{buildroot}}%{_sharedstatedir} \\\ mandir=%{?buildroot:%{buildroot}}%{_mandir} \\\ infodir=%{?buildroot:%{buildroot}}%{_infodir} \\\ install %_prefix /usr %_exec_prefix %{_prefix} %_bindir %{_exec_prefix}/bin %_sbindir %{_exec_prefix}/sbin %_libexecdir %{_exec_prefix}/libexec %_datadir %{_prefix}/share %_sysconfdir %{_prefix}/etc %_sharedstatedir %{_prefix}/com %_localstatedir %{_prefix}/var Laca From john.fischer@oracle.com Wed May 5 10:07:43 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o45H7hhg001265 for ; Wed, 5 May 2010 10:07:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45H7hFC029043 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 May 2010 10:07:43 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Y0010BI8VZB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 10:07:43 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00KKCI8TZD60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 May 2010 10:07:41 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45H7fCD004813 for ; Wed, 05 May 2010 17:07:41 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45082DO019404; Wed, 05 May 2010 17:07:38 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 216867871273079249; Wed, 05 May 2010 10:07:29 -0700 Received: from [10.7.250.1] (/10.7.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 10:07:28 -0700 Date: Wed, 05 May 2010 10:07:24 -0700 From: John Fischer Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <1273025740.13184.58.camel@tecra> To: "Laszlo (Laca) Peter" Cc: Alan Coopersmith , Brian Cameron , Doug Leavitt , Albert Lee , Sebastien Roy , PSARC-ext Message-id: <4BE1A5CC.9010806@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE1A5DA.00BE:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <1272929905.13184.16.camel@tecra> <4BE05234.1020200@oracle.com> <1273021401.13184.49.camel@tecra> <4BE0C5EB.80405@oracle.com> <1273025740.13184.58.camel@tecra> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 2283 All, I have extended the timer to Friday, May 7th, 2010. Thanks, John On 05/ 4/10 07:15 PM, Laszlo (Laca) Peter wrote: > On Tue, 2010-05-04 at 18:12 -0700, Alan Coopersmith wrote: > >> Laszlo (Laca) Peter wrote: >> >>> Like you say, the GNOME project provides common Makefiles in >>> gnome-common. GNU make does not come with useful standard >>> Makefiles AFAIK. >>> >> GNU& Solaris make both come with makefile fragments included >> by default to define useful standard rules like >> >> .c.o: >> $(CC) -c $@ $< >> >> See /usr/share/lib/make/make.rules for Solaris make - I believe >> GNU make's are hardcoded in the gmake binary. >> >> Whether something similar makes sense for pkgbuild, either now >> or in a later case, is a different question. >> > I think the equivalent in pkgbuild would be the macros file > (which was adopted from rpmbuild's macros file) that lives in > $(libdir)/pkgbuild-$(version)/macros > > It includes some standard macro definitions like: > > %makeinstall \ > make \\\ > prefix=%{?buildroot:%{buildroot}}%{_prefix} \\\ > exec_prefix=%{?buildroot:%{buildroot}}%{_exec_prefix} \\\ > bindir=%{?buildroot:%{buildroot}}%{_bindir} \\\ > sbindir=%{?buildroot:%{buildroot}}%{_sbindir} \\\ > sysconfdir=%{?buildroot:%{buildroot}}%{_sysconfdir} \\\ > datadir=%{?buildroot:%{buildroot}}%{_datadir} \\\ > includedir=%{?buildroot:%{buildroot}}%{_includedir} \\\ > libdir=%{?buildroot:%{buildroot}}%{_libdir} \\\ > libexecdir=%{?buildroot:%{buildroot}}%{_libexecdir} \\\ > localstatedir=%{?buildroot:%{buildroot}}%{_localstatedir} \\\ > sharedstatedir=%{?buildroot:%{buildroot}}%{_sharedstatedir} \\\ > mandir=%{?buildroot:%{buildroot}}%{_mandir} \\\ > infodir=%{?buildroot:%{buildroot}}%{_infodir} \\\ > install > > %_prefix /usr > %_exec_prefix %{_prefix} > %_bindir %{_exec_prefix}/bin > %_sbindir %{_exec_prefix}/sbin > %_libexecdir %{_exec_prefix}/libexec > %_datadir %{_prefix}/share > %_sysconfdir %{_prefix}/etc > %_sharedstatedir %{_prefix}/com > %_localstatedir %{_prefix}/var > > Laca > > > From john.fischer@oracle.com Fri May 7 11:00:34 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o47I0Yg0029658 for ; Fri, 7 May 2010 11:00:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o47I0WxL027891; Fri, 7 May 2010 11:00:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L220092RA0WMN00@nwk-avmta-2.sfbay.sun.com>; Fri, 07 May 2010 11:00:32 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L22004IKA0SJ650@nwk-avmta-2.sfbay.sun.com>; Fri, 07 May 2010 11:00:29 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o47I0Sp2006743; Fri, 07 May 2010 18:00:28 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o47C9brC016209; Fri, 07 May 2010 18:00:23 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 223589031273255209; Fri, 07 May 2010 11:00:09 -0700 Received: from [10.7.250.1] (/10.7.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 May 2010 11:00:08 -0700 Date: Fri, 07 May 2010 11:00:07 -0700 From: John Fischer Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDEFF73.5030404@oracle.com> To: Doug Leavitt Cc: "Laszlo (Laca) Peter" , Brian Cameron , Albert Lee , Sebastien Roy , PSARC-ext Message-id: <4BE45527.4080500@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_If8Jz47Rnb/tCFmjmveaAw)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE45538.019D:SCFMA4539814,ss=1,vtr=str,vl=0,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 23600 This is a multi-part message in MIME format. --Boundary_(ID_If8Jz47Rnb/tCFmjmveaAw) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Doug, Does the attached document satisfy this request for additional documentation? Laca, if not please provide what Doug is requesting. I will extend the timer for another few days to address the request. Thanks, John On 05/ 3/10 09:53 AM, Doug Leavitt wrote: > In addition to the missing definitions for the > Meta(*.*), SUNW*, and IPS* keys commonly deployed > in pkgbuils spec files today, I also noticed that neither > the proposal or the case materials make any reference to > > %include Solaris.inc > > or any of the include files Solaris.inc ifself includes and > that are generally expected as part of current pkgbuild > spec files, > > > I believe that this ARC case needs to at least document > and (hopefully) set some level of commitment to the > well defined tag list. > > At a minimum this: > http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/specdesc > > needs to be included in the ARC materials. > > But, I'm sure better documentation than above > should be provided. Say perhaps a man page or two? > > Doug. > > > > On 05/ 1/10 02:16 AM, Brian Cameron wrote: >> Albert: >> >>>>> The spec file syntax is also conceptually an exported interface, >>>>> and it >>>>> needs a stability level. It would be nice if the spec file syntax >>>>> were >>>>> part of the materials (I'm guessing it's documented somewhere >>>>> anyway). >>> The basic syntax is the same as rpmbuild spec files, and pkgbuild >>> includes >>> a set of predefined macros and supports some additional tags >>> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php >> True, although pkgbuild does support some Solaris/OpenSolaris specific >> extensions, and it might be good to highlight those a bit more. >> >> For example, one thing I notice is that the new "IPS_package_name" >> and "Meta(info.classification)" keys cause syntax errors if you try >> to use an older version of pkgbuild. It would be nice if pkgbuild >> had better backwards compatibility support and provided some mechanism >> to allow people who just want to build SVR5 packages a way to tell >> pkgbuild to ignore keys that provide features that are not going to be >> used anyway. >> >> Brian >> --Boundary_(ID_If8Jz47Rnb/tCFmjmveaAw) Content-type: application/pdf; name=specdesc.pdf Content-transfer-encoding: base64 Content-disposition: attachment; filename=specdesc.pdf JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoQXBhY2hlIEZPUCBWZXJzaW9u IHN2bi10cnVuaykKL1Byb2R1Y2VyIChBcGFjaGUgRk9QIFZlcnNpb24gc3ZuLXRydW5rKQov Q3JlYXRpb25EYXRlIChEOjIwMTAwNTA3MTc1NzEyWikKPj4KZW5kb2JqCjUgMCBvYmoKPDwK ICAvTiAzCiAgL0xlbmd0aCAxMSAwIFIKICAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl YW0KeJydlndUU9kWh8+9N71QkhCKlNBraFICSA29SJEuKjEJEErAkAAiNkRUcERRkaYIMijg gKNDkbEiioUBUbHrBBlE1HFwFBuWSWStGd+8ee/Nm98f935rn73P3Wfvfda6AJD8gwXCTFgJ gAyhWBTh58WIjYtnYAcBDPAAA2wA4HCzs0IW+EYCmQJ82IxsmRP4F726DiD5+yrTP4zBAP+f lLlZIjEAUJiM5/L42VwZF8k4PVecJbdPyZi2NE3OMErOIlmCMlaTc/IsW3z2mWUPOfMyhDwZ y3PO4mXw5Nwn4405Er6MkWAZF+cI+LkyviZjg3RJhkDGb+SxGXxONgAoktwu5nNTZGwtY5Io MoIt43kA4EjJX/DSL1jMzxPLD8XOzFouEiSniBkmXFOGjZMTi+HPz03ni8XMMA43jSPiMdiZ GVkc4XIAZs/8WRR5bRmyIjvYODk4MG0tbb4o1H9d/JuS93aWXoR/7hlEH/jD9ld+mQ0AsKZl tdn6h21pFQBd6wFQu/2HzWAvAIqyvnUOfXEeunxeUsTiLGcrq9zcXEsBn2spL+jv+p8Of0Nf fM9Svt3v5WF485M4knQxQ143bmZ6pkTEyM7icPkM5p+H+B8H/nUeFhH8JL6IL5RFRMumTCBM lrVbyBOIBZlChkD4n5r4D8P+pNm5lona+BHQllgCpSEaQH4eACgqESAJe2Qr0O99C8ZHA/nN i9GZmJ37z4L+fVe4TP7IFiR/jmNHRDK4ElHO7Jr8WgI0IABFQAPqQBvoAxPABLbAEbgAD+AD AkEoiARxYDHgghSQAUQgFxSAtaAYlIKtYCeoBnWgETSDNnAYdIFj4DQ4By6By2AE3AFSMA6e gCnwCsxAEISFyBAVUod0IEPIHLKFWJAb5AMFQxFQHJQIJUNCSAIVQOugUqgcqobqoWboW+go dBq6AA1Dt6BRaBL6FXoHIzAJpsFasBFsBbNgTzgIjoQXwcnwMjgfLoK3wJVwA3wQ7oRPw5fg EVgKP4GnEYAQETqiizARFsJGQpF4JAkRIauQEqQCaUDakB6kH7mKSJGnyFsUBkVFMVBMlAvK HxWF4qKWoVahNqOqUQdQnag+1FXUKGoK9RFNRmuizdHO6AB0LDoZnYsuRlegm9Ad6LPoEfQ4 +hUGg6FjjDGOGH9MHCYVswKzGbMb0445hRnGjGGmsVisOtYc64oNxXKwYmwxtgp7EHsSewU7 jn2DI+J0cLY4X1w8TogrxFXgWnAncFdwE7gZvBLeEO+MD8Xz8MvxZfhGfA9+CD+OnyEoE4wJ roRIQiphLaGS0EY4S7hLeEEkEvWITsRwooC4hlhJPEQ8TxwlviVRSGYkNimBJCFtIe0nnSLd Ir0gk8lGZA9yPFlM3kJuJp8h3ye/UaAqWCoEKPAUVivUKHQqXFF4pohXNFT0VFysmK9YoXhE cUjxqRJeyUiJrcRRWqVUo3RU6YbStDJV2UY5VDlDebNyi/IF5UcULMWI4kPhUYoo+yhnKGNU hKpPZVO51HXURupZ6jgNQzOmBdBSaaW0b2iDtCkVioqdSrRKnkqNynEVKR2hG9ED6On0Mvph +nX6O1UtVU9Vvuom1TbVK6qv1eaoeajx1UrU2tVG1N6pM9R91NPUt6l3qd/TQGmYaYRr5Grs 0Tir8XQObY7LHO6ckjmH59zWhDXNNCM0V2ju0xzQnNbS1vLTytKq0jqj9VSbru2hnaq9Q/uE 9qQOVcdNR6CzQ+ekzmOGCsOTkc6oZPQxpnQ1df11Jbr1uoO6M3rGelF6hXrtevf0Cfos/ST9 Hfq9+lMGOgYhBgUGrQa3DfGGLMMUw12G/YavjYyNYow2GHUZPTJWMw4wzjduNb5rQjZxN1lm 0mByzRRjyjJNM91tetkMNrM3SzGrMRsyh80dzAXmu82HLdAWThZCiwaLG0wS05OZw2xljlrS LYMtCy27LJ9ZGVjFW22z6rf6aG1vnW7daH3HhmITaFNo02Pzq62ZLde2xvbaXPJc37mr53bP fW5nbse322N3055qH2K/wb7X/oODo4PIoc1h0tHAMdGx1vEGi8YKY21mnXdCO3k5rXY65vTW 2cFZ7HzY+RcXpkuaS4vLo3nG8/jzGueNueq5clzrXaVuDLdEt71uUnddd457g/sDD30PnkeT x4SnqWeq50HPZ17WXiKvDq/XbGf2SvYpb8Tbz7vEe9CH4hPlU+1z31fPN9m31XfKz95vhd8p f7R/kP82/xsBWgHcgOaAqUDHwJWBfUGkoAVB1UEPgs2CRcE9IXBIYMj2kLvzDecL53eFgtCA 0O2h98KMw5aFfR+OCQ8Lrwl/GGETURDRv4C6YMmClgWvIr0iyyLvRJlESaJ6oxWjE6Kbo1/H eMeUx0hjrWJXxl6K04gTxHXHY+Oj45vipxf6LNy5cDzBPqE44foi40V5iy4s1licvvj4EsUl nCVHEtGJMYktie85oZwGzvTSgKW1S6e4bO4u7hOeB28Hb5Lvyi/nTyS5JpUnPUp2Td6ePJni nlKR8lTAFlQLnqf6p9alvk4LTduf9ik9Jr09A5eRmHFUSBGmCfsytTPzMoezzLOKs6TLnJft XDYlChI1ZUPZi7K7xTTZz9SAxESyXjKa45ZTk/MmNzr3SJ5ynjBvYLnZ8k3LJ/J9879egVrB XdFboFuwtmB0pefK+lXQqqWrelfrry5aPb7Gb82BtYS1aWt/KLQuLC98uS5mXU+RVtGaorH1 futbixWKRcU3NrhsqNuI2ijYOLhp7qaqTR9LeCUXS61LK0rfb+ZuvviVzVeVX33akrRlsMyh bM9WzFbh1uvb3LcdKFcuzy8f2x6yvXMHY0fJjpc7l+y8UGFXUbeLsEuyS1oZXNldZVC1tep9 dUr1SI1XTXutZu2m2te7ebuv7PHY01anVVda926vYO/Ner/6zgajhop9mH05+x42Rjf2f836 urlJo6m06cN+4X7pgYgDfc2Ozc0tmi1lrXCrpHXyYMLBy994f9Pdxmyrb6e3lx4ChySHHn+b +O31w0GHe4+wjrR9Z/hdbQe1o6QT6lzeOdWV0iXtjusePhp4tLfHpafje8vv9x/TPVZzXOV4 2QnCiaITn07mn5w+lXXq6enk02O9S3rvnIk9c60vvG/wbNDZ8+d8z53p9+w/ed71/LELzheO XmRd7LrkcKlzwH6g4wf7HzoGHQY7hxyHui87Xe4Znjd84or7ldNXva+euxZw7dLI/JHh61HX b95IuCG9ybv56Fb6ree3c27P3FlzF3235J7SvYr7mvcbfjT9sV3qID0+6j068GDBgztj3LEn P2X/9H686CH5YcWEzkTzI9tHxyZ9Jy8/Xvh4/EnWk5mnxT8r/1z7zOTZd794/DIwFTs1/lz0 /NOvm1+ov9j/0u5l73TY9P1XGa9mXpe8UX9z4C3rbf+7mHcTM7nvse8rP5h+6PkY9PHup4xP n34D94Tz+wplbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKWy9JQ0NCYXNlZCA1IDAgUl0KZW5k b2JqCjcgMCBvYmoKPDwKICAvVHlwZSAvTWV0YWRhdGEKICAvU3VidHlwZSAvWE1MCiAgL0xl bmd0aCAxMiAwIFIKPj4Kc3RyZWFtCjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1w Q2VoaUh6cmVTek5UY3prYzlkIj8+Cgo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1l dGEvIj4KPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIy LXJkZi1zeW50YXgtbnMjIj4KPHJkZjpEZXNjcmlwdGlvbiB4bWxuczpkYz0iaHR0cDovL3B1 cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iIHJkZjphYm91dD0iIj4KPGRjOmRhdGU+CjxyZGY6 U2VxPgo8cmRmOmxpPjIwMTAtMDUtMDdUMTc6NTc6MTJaPC9yZGY6bGk+CjwvcmRmOlNlcT4K PC9kYzpkYXRlPgo8L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiB4bWxuczpw ZGY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8iIHJkZjphYm91dD0iIj4KPHBkZjpQ REZWZXJzaW9uPjEuNDwvcGRmOlBERlZlcnNpb24+CjxwZGY6UHJvZHVjZXI+QXBhY2hlIEZP UCBWZXJzaW9uIHN2bi10cnVuazwvcGRmOlByb2R1Y2VyPgo8L3JkZjpEZXNjcmlwdGlvbj4K PHJkZjpEZXNjcmlwdGlvbiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC8iIHJkZjphYm91dD0iIj4KPHhtcDpDcmVhdGVEYXRlPjIwMTAtMDUtMDdUMTc6NTc6MTJa PC94bXA6Q3JlYXRlRGF0ZT4KPHhtcDpDcmVhdG9yVG9vbD5BcGFjaGUgRk9QIFZlcnNpb24g c3ZuLXRydW5rPC94bXA6Q3JlYXRvclRvb2w+Cjx4bXA6TWV0YWRhdGFEYXRlPjIwMTAtMDUt MDdUMTc6NTc6MTJaPC94bXA6TWV0YWRhdGFEYXRlPgo8L3JkZjpEZXNjcmlwdGlvbj4KPC9y ZGY6UkRGPgo8L3g6eG1wbWV0YT4KPD94cGFja2V0IGVuZD0iciI/PgoKCmVuZHN0cmVhbQpl bmRvYmoKMTAgMCBvYmoKPDwgL0xlbmd0aCAxMyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCnicbY/LTgMxDEX3+QovYUHGjzzsLhHtgt2I7BALNAxopE5boP8vrHakthKK kij35h7bBOjrgfzQRFFVrVbMMMzhO9DJJKjslyu9a/2Vnlki13wxrwK1mNPsP4dv6b5PAISv 8NhCt6lACu1z+eC9UUqREpkpG3jBSMhmRQXaDK93L4dxgM20HeFp/B1+psNx2u/u36A9OyyD 3bCYUhQtZpL8YRxrQdMiC+v9Y56W7KW8SazZELkYCErMhRBTSecII1pH2HEB4pXQOb1uPncf /gDCQEorCmVuZHN0cmVhbQplbmRvYmoKOCAwIG9iago8PAogIC9SZXNvdXJjZXMgMyAwIFIK ICAvVHlwZSAvUGFnZQogIC9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCiAgL0JsZWVkQm94IFsw IDAgNTk1IDg0Ml0KICAvVHJpbUJveCBbMCAwIDU5NSA4NDJdCiAgL1BhcmVudCAxIDAgUgog IC9Db250ZW50cyAxMCAwIFIKPj4KCmVuZG9iagoxMSAwIG9iagoyNTk2CmVuZG9iagoxMiAw IG9iago4MzAKZW5kb2JqCjEzIDAgb2JqCjIxMgplbmRvYmoKMTUgMCBvYmoKPDwgL1VSSSAo ZmlsZTovb3B0L29zby94d2lraS90ZW1wL3h3aWtpL2R5aFVsM09mL0NvbW11bml0eSUyMEdy b3VwJTIwc3clMkRwb3J0ZXJzLnNwZWNkZXNjLnRtcGwuc3BlYy50eHQpCi9TIC9VUkkgPj4K ZW5kb2JqCjE2IDAgb2JqCjw8IC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb IDI1OC40NjIgNzE1Ljk3OSAzMjEuOTQ4IDcyNC4wNzkgXQovQyBbIDAgMCAwIF0KL0JvcmRl ciBbIDAgMCAwIF0KL0EgMTUgMCBSCi9IIC9JCgo+PgplbmRvYmoKMTggMCBvYmoKPDwgL1VS SSAoZmlsZTovb3B0L29zby94d2lraS90ZW1wL3h3aWtpL2R5aFVsM09mL0NvbW11bml0eSUy MEdyb3VwJTIwc3clMkRwb3J0ZXJzLnNwZWNkZXNjLm5hbm8uc3BlYy50eHQpCi9TIC9VUkkg Pj4KZW5kb2JqCjE5IDAgb2JqCjw8IC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbIDk2LjAgMTY3LjM5MyAxNDUuOTg2IDE3NS40OTMgXQovQyBbIDAgMCAwIF0KL0JvcmRl ciBbIDAgMCAwIF0KL0EgMTggMCBSCi9IIC9JCgo+PgplbmRvYmoKMjAgMCBvYmoKPDwgL0xl bmd0aCAyMSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnicnVhZb9tGEH73 r1ggMJAW9Zp7cw20D2maHkjapHbSBzkIaGols+VVkmprBPnv/ZaHSImUU1SGD1Ez3xw7882s GQnwdcHwI5SMhmFojQkUibOzP89Y+yEjhuMXngRke/bs5uzyhSIsIDebXgDajBkaam2tNoZI SYUIgoCFgtxkZPX02yLLdnnSPJDvq2JXkvrvi7KoGlfV5IJcly4mL5LUkeeujqukbJIi/+I9 ufnp7Lubszdw483EFcUF5UZ1/rw59NFoiwDs5zwNaSg43DOCCH7k6eto60hnfNSQATUGGoKZ uYaYSatHpBFvGtUNyYp1skncmtw9kGidJTkpcgIle8mCS64J41eCHSRhGic/CNEQJqg6CBKC DGmyMM3DzvIjaW4hAqrEEYYQVHKfKeT0CMP/hQDiaIqiiD1CUIxaZbpcd/H/4CpHkpo0947E u6pyeUNKl6+TfEuifE3iIm+q5I5UrizqpCmqh9lxhJJyBreU5gsGOukuV9V2qqap1KfUah/Z xkfWuKxMo8btk79X1Cg+GjKG4yQaqQk1CSiXEr6SzbTiDrPApaVWGmtDtNUpf0dp2GD2lDQd Um2JodIcZVuH1BoJVf+JF39yBB4QY6gVKAtu+yN9QsbQN0VFyij+Az1wRVblH1uSR5l7PwNB QqxHsGF4yo5VIx30dm7uceytHX/OUZr2TdDVUN09Xa+T7l1TtCVSVkndJLmbGWCBRBv7sxgK /MngO4lwILt87aoWokYMJE1il9f4qKu8QTJpapdu6BwdHWWsTyU7mUrGOTXK51Lvc5nkcbpb u9qHtkvd7dP69os+lZMn84wywajhYAq09ilzKCOtEHBg+4DPe2vkukgj5Ini/VxNG6pMaFGB qlP7Gfm4IuPrkYNmRlMl/UnzPg3XuyyLqoe9/qq+B5GT9UgpCyihoipAGQvTe/4OzA/RqwMX /uoeLuhbiVoPrBWB7PRfdqc56g/H2zyUjtw+TRwl379++Rf/ijy7fk4pXco5D9DDAmdslO5g 31bpNDFktatSX4gFCIrUxa6KfUEWv7u4WYBj4HrryyEYGLfVuJrBxUVWVq6uwf5NVN2hExbQ OKNCoyC06ovrORoBxLhrusT9Ap/6c58ri4AKVKVVoRoSnq+LanRlok32w3kBx1JufcmJ/vif 7ZJ0/WtRND3U+ccPTVaWUXP/6fL8oy+iTxfnH/uT/HRx58XnsDKkXKkgkAN/XL/9+bcPzyJk JGmdBOxd9+7TXFsZ0L8vaCYn2t8W5UOVbO/hWe8IjYdHcwyjKJOmm9GHvbR2m2iXNhdr56fS YktxDCBMATSFFNO0uD93Cc4V/d7GTXxRdzAujxOQwu3T63eV3JOP93KRDbgVNDAK1MZZZ2CC Xe3yJgGj/W90gdWgHQAj2RzUw4+vr8nrHuRVlCcbh33lReLS9bzSBMNs0yZgQV9or1wTof/y TUF3JQrWRZlnwGlTeceIy6IkJcVmqbdI6iKQ94LnHANOIPHW6Jk5AOYNvl11YPDIXFLWbea6 9fNyVFqwJrDSYgaENmAza+N68gFdvbe4moYTF6inUXDBgtQ09BMkNHZmIcaeWO/H42hhiODw 8wVwLakJtQ2H3eF8fbz3TaUNBp6fLmZgr1Va5NvHiV1YRjVmSzgQ6Dl4rZyJySCgWoLL1EAj K8h15ODJMMPkr+foEou6Mixgsu/z82U6kRwTToBOhO7dWH0WGju6BLsyPrZ/3YCI55IKs4eD KZjtK3zViz4GbzAKQHCeI3r8GDU9z7oMwfKs3dL7GFetIK5Ij6BbsLInLztsPud+q5o3pwrA s96HUA3o7fq19Xewbt8qXZUltSfrBUOKa8pEfx/sw7iP8q1Li+1cWIBSAxFwI/ahtMIE0sT5 pd4NNk7dNxRKFhWIuaXZ8YXju38i7OVDlIt3jZBjWYEHduim7rLht8G68Iz5+DVj3INdb+t4 L2RYOVFnqLSQaBT1obVbztWpyweOd66QR3kxWt3fN1pZ1IXVFq3rLw8nLhrLSdTYHAKNJArW t4Mn9D2RY/8Yk/oqKktk5HRONTYAfXCqBxc4jzzMm2xiYUxl1ln4zL1FaYoLljVM9xX9pac4 2lL39PX1N6TdXmfVpzVWTJwNx9VpilB36+oBwrDCzkGMxAmB7RkXA8iE//4jSIi7OPN3fmkH kINx6OdFD/L215cLAJYjQ+BtOyzsPUA3VQb1zotuw5z8n+BfUMqcSAplbmRzdHJlYW0KZW5k b2JqCjE3IDAgb2JqClsKMTYgMCBSCjE5IDAgUgpdCmVuZG9iagoxNCAwIG9iago8PAogIC9S ZXNvdXJjZXMgMyAwIFIKICAvVHlwZSAvUGFnZQogIC9NZWRpYUJveCBbMCAwIDU5NSA4NDJd CiAgL0JsZWVkQm94IFswIDAgNTk1IDg0Ml0KICAvVHJpbUJveCBbMCAwIDU5NSA4NDJdCiAg L1BhcmVudCAxIDAgUgogIC9Bbm5vdHMgMTcgMCBSCiAgL0NvbnRlbnRzIDIwIDAgUgo+PgoK ZW5kb2JqCjIxIDAgb2JqCjE2NzEKZW5kb2JqCjIzIDAgb2JqCjw8IC9MZW5ndGggMjQgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4nJVW227cNhB991cMAhRNAi+XpC4U jdQPTesWRdM2tYs8NEUgS9xdIZKoiNo47tf3UNr1XiR7UxqWDVE8nDlz5iKI42cm8EhCwZIk 0UrxiLLq7NOZ6DcFKYk/eMNpefb9zdn8KiLB6Wax+QCnhVAsiWOtY6UoDFkQcM5FEtBNRX8/ f22ral0X3T391Np1Q+5u1ti2M62jGV03JqOrojT0g3FZWzRdYesX/9DNL2c/3py9hRlv90yJ ZMCkigZ73h7aqGINB/QpSxOWBBLmqYACeWTpH+nS0HD57kTImVI4EQg1PhGOvo6e+Br+lqnr qLJ5sShMTrf3lOZVUZOtCYf0XPC5jEnIi0AckLDvpzxwUZNioTpwklPMZBhqrUFHf/FLKuqF ZRlud7g5Sz3LRN9d0hvTpe+fT+y+f3HkGq6PmOQJYONgC1sWmamdoe6+MbRdgP11eH8xwpAh E8qTEoTHGAuvgj2M679+e/fhtW3u22K56sZQQcBEoEAvDw+8XDeua01a7UHtebndnfAvlEwA jQt1CFilRd3h17RTgLvdCchIMB4jEsmOsv5Qaxrris629x/WbXkMebg7ARtzxqWPRPAA23xc shwQIDEfMPctPd7dYs6vFFKERcGRgJKEARt2CzFcsMvTPx+M20JEpI+OCw5RxtpTqTbSf2co bQ28p25lqGltZpwju6DcLIq6qJd4XzhGP5t2+NLZCp/nJnWMse1Vk2oXEFWYoPzoaGMtEc7M XyHP1qW5ZM4b36/ZJfl4Uf+mF9z752uHTFzYlm7XRZnDkrHwIbUwgjJCvs3kx9bvjamvbZm2 haPMVg1y6Ra3NGn2EcXFjaEhulBAIYHU+7bfps7MvJXu0I2JpBQsUNCCSp4yDY47S1laQgD0 zKP3HLhn59T7j0qEuIzRobQgRL7KQJ7w/JBXBzY7qs1nJE1Rf7YfTT4BrlnAkcFxEp4Az4vW ZF15P8ZQCToCR03iB/yB+GxlduTNXtU1HvmuyVwyFOHFGDBRTAYRKlQsThK6bjODMOd4rNIa 8T3fChx6qqDuMbyOmdDIjEicktKsEYS+2TcKb+pYPJJHTMRS6zB4MvhYWx4uqE6RV8g7b+Xw 8pwMW7IxukCtlvGuizwKPqxljYydNWltyjEWGjfXwpf9UzrygbogOcuLZdFRH0eq19Wtac9R KzA2oF9OJBIEyniERJLxKS6G5f23bd7rk+5WBa7pK9MgHF+CJpoXyrnwuSa+jpK0aUofvs72 2INgJmwPNdNJ4Mvlk5rz7Owr+KJH3Q/oQFdRj6+IUNFRkjXX6utMh67XTdkj34En95hKYsW0 8H1TnUriYa1Q02duZe9mdyaFze0YUsUswZS3l85FnZXr3MxfMvxHQ/Y9lPBFmy4rU3eOvtl8 920+yUESYfhLoGfMWP+rmA2+06awexvG4DpkCUcM9a5HeMuz7QCzq+MPr8YjDQ+Y8oN0Ip8U GNx/ABksHEMJyTBoaRB5wKT50s02Opy/HKCsj8Kmah82QyTIpnWhLZ6P75CCxTryw/SprPaQ 5ktaeUVdv7kCwahsxnUThgecxRGSDI99w3Gi8S10vuNgr9n2vdIPrx55nZbUTLZbzDQsllIn 0a7l9O3CzizA3AA2fxS8tGihxb/9hOwwO1QYYnDR+J4wYVGC1hbFp5jBuJ2Wdum2I1k/8f8H Xrlb0gplbmRzdHJlYW0KZW5kb2JqCjIyIDAgb2JqCjw8CiAgL1Jlc291cmNlcyAzIDAgUgog IC9UeXBlIC9QYWdlCiAgL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KICAvQmxlZWRCb3ggWzAg MCA1OTUgODQyXQogIC9UcmltQm94IFswIDAgNTk1IDg0Ml0KICAvUGFyZW50IDEgMCBSCiAg L0NvbnRlbnRzIDIzIDAgUgo+PgoKZW5kb2JqCjI0IDAgb2JqCjEyNjgKZW5kb2JqCjI2IDAg b2JqCjw8IC9UeXBlIC9BY3Rpb24KL1MgL0dvVG8KL0QgWzE0IDAgUiAvWFlaIDcyLjAgNzY5 Ljg4OSBudWxsXQo+PgplbmRvYmoKMjcgMCBvYmoKPDwgL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFsgNzguMCA2ODcuNjM5IDE1Ny42MzQgNjk1LjczOSBdCi9DIFsgMCAw IDAgXQovQm9yZGVyIFsgMCAwIDAgXQovQSAyNiAwIFIKL0ggL0kKCj4+CmVuZG9iagoyOSAw IG9iago8PCAvVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWyA1MTguNjY0IDY4 Ny42MzkgNTIzLjE2NCA2OTUuNzM5IF0KL0MgWyAwIDAgMCBdCi9Cb3JkZXIgWyAwIDAgMCBd Ci9BIDI2IDAgUgovSCAvSQoKPj4KZW5kb2JqCjMwIDAgb2JqCjw8IC9UeXBlIC9BY3Rpb24K L1MgL0dvVG8KL0QgWzE0IDAgUiAvWFlaIDcyLjAgNzUzLjY4OSBudWxsXQo+PgplbmRvYmoK MzEgMCBvYmoKPDwgL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsgODQuMCA2 NzYuODM5IDE2OS4wOTMgNjg0LjkzOSBdCi9DIFsgMCAwIDAgXQovQm9yZGVyIFsgMCAwIDAg XQovQSAzMCAwIFIKL0ggL0kKCj4+CmVuZG9iagozMiAwIG9iago8PCAvVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWyA1MTguNjYzIDY3Ni44MzkgNTIzLjE2MyA2ODQuOTM5 IF0KL0MgWyAwIDAgMCBdCi9Cb3JkZXIgWyAwIDAgMCBdCi9BIDMwIDAgUgovSCAvSQoKPj4K ZW5kb2JqCjMzIDAgb2JqCjw8IC9UeXBlIC9BY3Rpb24KL1MgL0dvVG8KL0QgWzE0IDAgUiAv WFlaIDcyLjAgMjIzLjEwMyBudWxsXQo+PgplbmRvYmoKMzQgMCBvYmoKPDwgL1R5cGUgL0Fu bm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsgODQuMCA2NjYuMDM5IDE1Ny4xNjMgNjc0LjEz OSBdCi9DIFsgMCAwIDAgXQovQm9yZGVyIFsgMCAwIDAgXQovQSAzMyAwIFIKL0ggL0kKCj4+ CmVuZG9iagozNSAwIG9iago8PCAvVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WyA1MTguNjYyIDY2Ni4wMzkgNTIzLjE2MiA2NzQuMTM5IF0KL0MgWyAwIDAgMCBdCi9Cb3Jk ZXIgWyAwIDAgMCBdCi9BIDMzIDAgUgovSCAvSQoKPj4KZW5kb2JqCjM2IDAgb2JqCjw8IC9U eXBlIC9BY3Rpb24KL1MgL0dvVG8KL0QgWzE0IDAgUiAvWFlaIDcyLjAgMTY2LjA0MyBudWxs XQo+PgplbmRvYmoKMzcgMCBvYmoKPDwgL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFsgODQuMCA2NTUuMjM5IDIxNC42MTUgNjYzLjMzOSBdCi9DIFsgMCAwIDAgXQovQm9y ZGVyIFsgMCAwIDAgXQovQSAzNiAwIFIKL0ggL0kKCj4+CmVuZG9iagozOCAwIG9iago8PCAv VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWyA1MTguNSA2NTUuMjM5IDUyMy4w IDY2My4zMzkgXQovQyBbIDAgMCAwIF0KL0JvcmRlciBbIDAgMCAwIF0KL0EgMzYgMCBSCi9I IC9JCgo+PgplbmRvYmoKMzkgMCBvYmoKPDwgL1R5cGUgL0FjdGlvbgovUyAvR29UbwovRCBb MjIgMCBSIC9YWVogNzIuMCA2OTguMTc3IG51bGxdCj4+CmVuZG9iago0MCAwIG9iago8PCAv VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWyA4NC4wIDY0NC40MzkgMTYxLjE0 NiA2NTIuNTM5IF0KL0MgWyAwIDAgMCBdCi9Cb3JkZXIgWyAwIDAgMCBdCi9BIDM5IDAgUgov SCAvSQoKPj4KZW5kb2JqCjQxIDAgb2JqCjw8IC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu awovUmVjdCBbIDUxOC42NjMgNjQ0LjQzOSA1MjMuMTYzIDY1Mi41MzkgXQovQyBbIDAgMCAw IF0KL0JvcmRlciBbIDAgMCAwIF0KL0EgMzkgMCBSCi9IIC9JCgo+PgplbmRvYmoKNDIgMCBv YmoKPDwgL0xlbmd0aCA0MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnic lZ1Lb1zHEUb3/BV3aS806nr0o7KMIwcJEMCKuQuyoCVKICA+ItJI9O/TNdSDM8MofWDAj3Hd mjMz1D2357vFlq3Mv17I/Ntw2Y0xovdStzfXZ/86k/3/lK3r/Md8pGzvz/54fvby57pJ2c7f fS6YR4v03WgtovW+ue/MSikybDu/3v7xw0+319e/31w9fNr+/PH297vt/t8v7m4/Plx+vN9e bL/eXb7Zfr76cLn96fL+zceru4er25sf/7md//Xs1fnZ64nx+glKVdtpr488rw8Ze4v5AuL/ kY7dMJ143TbTI9JfLt5fbo9P/u0IL7ve5xEm/fQIPamu36mer/fDxf3Ddn379urd1eXb7bdP 28Xb66ub7fZmmwfFSykvtW2ifzA5eBOevk49eIl9Uz94iWXz2GmViPlm7J/2/OK3+f7evtt+ ur15uLx5uH9snW9PHBzatlF2GvOD7KU/Hrv/fH7cXkTffth/TJ///eTT+tpk1F0zL0VbnLb7 cvjxMWPXa5/vWh+nx+yOikN28+NbLZ4/MOud666ud+6AWUoB0FIUUEtxgC2lIe4g3CKEW4xw SyXc88854NZCuFUJtzrh1o64g3CbEG4zwm2NcNsg3PMMDLhdCfc8XwNu74g7CHcVwl2dcNdG uOsg3K0Q7maEu1XC3TriDsLdlXB3J9y9Ee5OXCmDyHJeqBDuQXQpA/kykC8D+TKQLwP5Mogv tRBfaiG+1EJ8qYX4UoX4UoX4UoX4UoX4UoX4UpX4UpX4UpX4UpX4Uo34Uo34Uo34Uo34Uo34 Up34Up34Up34Up34UivxpVbiS63El7NycrcYo9pKdfpyubqlL9er05fr1Y1wt0G4uxDuboS7 V8LdO+EehXAPJdzDCfdoiDsIdwjhDiPcUQl3DMBtpQBuKwq4rTjgttIRdxBuEcItRrilEW4Z hFsL4VYl3FoJt3bEHYTbhHCbE25rhNsG4c7vX9d7uxFur4TbiS/NiS+tEl9aJb60SnxplfjS GvGlNeJLa8SX1ogvrRNfWie+tE58aZ340jrxpQ3iSxvElzaIL20gXwbyZSBfBvJlIF8G8aUX 4ksvxJdeiC+9EF+6EF+6EF+6EF+6EF+6EF+6El+6El+6El+6El+6EV+6EV+6EV+6EV+6EV/6 9Hz1EqOKnFb/j5TR57K+NS9F/Jmk046/ytN90jgL5gH6WPM1DfV9Vv4kEv3yQFZcvbt6c/FM MprnkphrAbVnWh90OUaZ6wdJ2NFODzz5CnIuH+YrXS32XVvv3Hax3jkA81w6rDPPlcM68zyh rDPPdcM681w2rDPPVcM68zyZrDPPNQNgjsk8K5raQvVcMrRYr7ZJvV7dJvZ69SDcc8kAuF0J 91wyAO65ZCDcQbirEO65ZADcc8kAuOeSAXC3QrjnkgFwzyUD4J5LBsIdhHsuGQD3XDIA7rlk ANx9EO65ZADcc8kAuPPWINC7E+4ohDuUcIcT7miIOwB3Bobr3BkYrnNnYLjOnYEh4JZCuEUJ tzjhlo64iS8zMATcSnyZgSHgVuLLDAwBtxFfZmAIuI34MgNDwO3ElxkYAm4nvszAEHBX4ssM DAF3Jb7MwHB/ETvLVqrj8Sp2rbrp42XsYrU/XnsvVjfC3Qbh7kK4uxHuXgl374R7FMI9lHAP J9yjIe4g3CGEO4xwRyXcMQB3Bobr3BkYrnNnYLjOnYEh4Q7CLUK4xQi3NMItg3BrIdyqhFsr 4daOuINwmxBuc8JtjXDbINxeCLcb4fZKuJ34MgNDwF2JLzMwBNyV+DIDQ8DdiC8zMATcjfgy A0PA3YkvMzAE3J34MgNDwk18mYEh4B7ElxkYAu6BfBnIl4F8GciXgXwZxJcZGK5zZ2C4zp2B 4Tp3BoaAW4gvMzAE3EJ8mYEh4Sa+zMAQcCvxZQaGgFuJLzMwBNxGfJmBIeA24ssMDAF3BoZ1 zGofp9XfC98eU0ONcHvmyGdSQ5l/TEcW5QzovuhrbDgmQ21PYsMvD7z6z8X13YfL+6Nu85Qp LRPDIs+0PehwfOTY5ehpsVKfOfL43Zmnz1rXq3U3QO+6K6B3R9xBuPcV680zGwXkmY4CdCkD sc9zKGGfiyXCPs+ihH2eRhF7IPa5YCLs80xK2OeplLDPcylhn4smwj7PpoR9nk4J+zyfEva5 cCLsrojdHbHPsy5iD8ReBbFXQ+y1Iva5gCLsrSD2poi9OWKfiyjEHoi9C2LvhtjnQoqwd6RU GcipMpBUM0ol7ANpVQbzajCvBvNqMK8G8qoW5NWMVAF7ZqqAXQvyqhbk1YxVCbsgr6ogr6og r2a0StgVeVUVeVUVeTXjVcJuyKtqyKtqyKsZsRJ2R15VR15VR17NmJWwV+RVrcirWpFXM2ot HjF6j6Xy2M0V6nJ5m14F3ZvtOuneEHsbiL0XxN4VsfeK2Htn7IHYhyD24Yh9NMQ+BmKPgtjD EHtUxB6dsQdhz/gVsGf+CtitNMJuZSB2EcQuhtilInbpiF0LYldF7OqIXRtjD8RugtjNELtV xG4DsXtB7K6I3R2xO/JqZrKEvSKvWkVezViWsFfkVWvIq9aQVzOaJewNedUa8qp15NWMZwl7 R161jrxqA3k1I1rCPpBXbSCv2mBeDebVYF4N5tVAXs2oFrBnVgvYvSCvekFezbiWsAvyqgvy qgvyaka2hF2RV12RV12RVzO2JeyGvOqGvOqGvJrRLWJHXt2Htzrb23PV34tBH8NbmU9kzxz5 XHgr3wb19jV/+eXXfIL9t7n5BH+7uLl6d3n/cPDgw+3Bf37Je78+8CXvfdLl7u7q5v3x889r nya1lPlBnZIcNDg5cp4RxnxHm/npkSffkc6roGHL1XWeD9Z71/ytx+vVTrjnFRDhDsLdhHA3 I9zz6gdwt0G4eyHcXQn3vPIB3L0j7iDcQwj3vOoB3KMR7ryzYr133lmx3jvvrAC9K+HOOytA 7wDcOZa2zq15XwXo3QB3jqUB7rypYr133lMBelfCnXdUgN5BuPN+ivXeeTsF6N0Id95Msd47 76VY7523UoDexJc5lga4nfhSnfgyx9IAtxNfqhNfaiW+zLE0wF2JL7USX2ojvsyxNMDdiC+1 EV9qI77MsTTA3YkvtRNfaie+zLE0wD2IL3UQX+ogvsyxNMAdyJeBfBnIl0F8mWNp69xWiC+t EF/mWBrhJr40Ib40Ib7MsTTALcSXpsSXpsSXOZYGuJX40oz40oz4MsfSALcRX5oRX5oTX+ZY GuB24ktz4kurxJc5lga4K/GlVeJLq8SXOZYGuBvxpTXiS2vElzmWBrg78aV14kvrxJc5lga4 B/GlDeJLG8SXOZYGuAP5MpAvA/kykC+D+NIL8aUX4sscS1vnzrE0wC3Ely7ElzmWBriF+NKV +NKV+DLH0gC3El+6El+6EV/mWBrgNuJLN+JLd+LLg2TjuPh7X/hnsFFPD3ku0ZgXep6xh7T6 WPRtT79JavZ0Y7/PD/z98u72/urh9uOno3752ze8lTJN8kzjgx5HR+YWPV82Rjw98vh9yS16 dL26fdt0caF6/hiu987UCIBLbtJDuleCnkNjhD336QHd508TYc+dekj3ztgDsedmPaB77tZD ujfEnvv1gO65YQ/onjv2kO4VseeePaR7IPbctQd0z217SPeG2HPjHtC9FsSeW/eQ7hWx5+Y9 pHsg9ty+B3TP/XtI94bYcwcf0D238AHdcw8f0r0i9tzFB3TPbXxA94GkKgNZNXNRxM68Gsyr wbwazKuBvJpDY4BdC/Jq5qOAPYfGEDvyqgryamakhF2QV3NojLAr8mrmpIRdkVdzaAyxI69m VkrYDXk1h8YIuyGvqiOv5tAYYXfkVXXk1cxMCXtFXs2hMcJekVczNyXsDXk1h8YIe0NezeyU sHfk1RwaI+wdeTXzU8SOvJpDY4R9IK9mhkrYB/NqMK8G82owrwbzaiCvWkFezSwVsOfQGGDP oTHCLsirmacSdkFeNUFeNUFezUyVsCvyag6NEXZFXs1clbAb8moOjRF2Q17NbJWwO/JqDo0R dkdezXyVsFfk1RwaI+wVeTUzVsLekFdzaIywN+TVzFkRO/JqDo0R9o68mlkrYe/Iqzk0RtgH 8mrmrYR9IK/m0BhhD+bVYF4N5tVAXvWCvJq5K2DPoTHAnkNjiB15NbNXwi7Iqzk0RtgFeTXz V8KuyKs5NEbYFXk1M1jCbsirOTRG2A15NXNYwu7Iq/skdjphPyl2Uv29ZPPgF4SeHuqP5a/O z16f/Rez9NVjCmVuZHN0cmVhbQplbmRvYmoKMjggMCBvYmoKWwoyNyAwIFIKMjkgMCBSCjMx IDAgUgozMiAwIFIKMzQgMCBSCjM1IDAgUgozNyAwIFIKMzggMCBSCjQwIDAgUgo0MSAwIFIK XQplbmRvYmoKMjUgMCBvYmoKPDwKICAvUmVzb3VyY2VzIDMgMCBSCiAgL1R5cGUgL1BhZ2UK ICAvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQogIC9CbGVlZEJveCBbMCAwIDU5NSA4NDJdCiAg L1RyaW1Cb3ggWzAgMCA1OTUgODQyXQogIC9QYXJlbnQgMSAwIFIKICAvQW5ub3RzIDI4IDAg UgogIC9Db250ZW50cyA0MiAwIFIKPj4KCmVuZG9iago0MyAwIG9iagozMTk3CmVuZG9iago0 NCAwIG9iago8PAogIC9UeXBlIC9Gb250CiAgL1N1YnR5cGUgL1R5cGUxCiAgL0Jhc2VGb250 IC9UaW1lcy1Sb21hbgogIC9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nCj4+CgplbmRvYmoK NDUgMCBvYmoKPDwKICAvVHlwZSAvRm9udAogIC9TdWJ0eXBlIC9UeXBlMQogIC9CYXNlRm9u dCAvQ291cmllcgogIC9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nCj4+CgplbmRvYmoKNDYg MCBvYmoKPDwKICAvVHlwZSAvRm9udAogIC9TdWJ0eXBlIC9UeXBlMQogIC9CYXNlRm9udCAv VGltZXMtQm9sZAogIC9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nCj4+CgplbmRvYmoKMSAw IG9iago8PCAvVHlwZSAvUGFnZXMKL0NvdW50IDQKL0tpZHMgWzggMCBSIDI1IDAgUiAxNCAw IFIgMjIgMCBSIF0gPj4KZW5kb2JqCjIgMCBvYmoKPDwKICAvVHlwZSAvQ2F0YWxvZwogIC9Q YWdlcyAxIDAgUgogIC9NZXRhZGF0YSA3IDAgUgogIC9QYWdlTGFiZWxzIDkgMCBSCj4+Cgpl bmRvYmoKMyAwIG9iago8PAovRm9udCA8PAogIC9GNSA0NCAwIFIKICAvRjkgNDUgMCBSCiAg L0Y3IDQ2IDAgUgo+PgovUHJvY1NldCBbIC9QREYgL0ltYWdlQiAvSW1hZ2VDIC9UZXh0IF0K L0NvbG9yU3BhY2UgPDwKICAvRGVmYXVsdFJHQiA2IDAgUgo+Pgo+PgplbmRvYmoKOSAwIG9i ago8PCAvTnVtcyBbMCA8PCAvUCAoMSkgPj4KIDEgPDwgL1AgKDIpID4+CiAyIDw8IC9QICgz KSA+PgogMyA8PCAvUCAoNCkgPj4KXSA+PgoKZW5kb2JqCnhyZWYKMCA0NwowMDAwMDAwMDAw IDY1NTM1IGYgCjAwMDAwMTQwMzcgMDAwMDAgbiAKMDAwMDAxNDExNiAwMDAwMCBuIAowMDAw MDE0MjA4IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMDE1MSAwMDAwMCBu IAowMDAwMDAyODMzIDAwMDAwIG4gCjAwMDAwMDI4NjYgMDAwMDAgbiAKMDAwMDAwNDA3NCAw MDAwMCBuIAowMDAwMDE0MzU4IDAwMDAwIG4gCjAwMDAwMDM3ODYgMDAwMDAgbiAKMDAwMDAw NDI0MSAwMDAwMCBuIAowMDAwMDA0MjYyIDAwMDAwIG4gCjAwMDAwMDQyODIgMDAwMDAgbiAK MDAwMDAwNjYyNiAwMDAwMCBuIAowMDAwMDA0MzAyIDAwMDAwIG4gCjAwMDAwMDQ0MzUgMDAw MDAgbiAKMDAwMDAwNjU5MiAwMDAwMCBuIAowMDAwMDA0NTc1IDAwMDAwIG4gCjAwMDAwMDQ3 MDggMDAwMDAgbiAKMDAwMDAwNDg0NSAwMDAwMCBuIAowMDAwMDA2ODExIDAwMDAwIG4gCjAw MDAwMDgxNzYgMDAwMDAgbiAKMDAwMDAwNjgzMiAwMDAwMCBuIAowMDAwMDA4MzQ0IDAwMDAw IG4gCjAwMDAwMTM1MDkgMDAwMDAgbiAKMDAwMDAwODM2NSAwMDAwMCBuIAowMDAwMDA4NDQ1 IDAwMDAwIG4gCjAwMDAwMTM0MTkgMDAwMDAgbiAKMDAwMDAwODU4MiAwMDAwMCBuIAowMDAw MDA4NzIyIDAwMDAwIG4gCjAwMDAwMDg4MDIgMDAwMDAgbiAKMDAwMDAwODkzOSAwMDAwMCBu IAowMDAwMDA5MDc5IDAwMDAwIG4gCjAwMDAwMDkxNTkgMDAwMDAgbiAKMDAwMDAwOTI5NiAw MDAwMCBuIAowMDAwMDA5NDM2IDAwMDAwIG4gCjAwMDAwMDk1MTYgMDAwMDAgbiAKMDAwMDAw OTY1MyAwMDAwMCBuIAowMDAwMDA5Nzg5IDAwMDAwIG4gCjAwMDAwMDk4NjkgMDAwMDAgbiAK MDAwMDAxMDAwNiAwMDAwMCBuIAowMDAwMDEwMTQ2IDAwMDAwIG4gCjAwMDAwMTM2OTQgMDAw MDAgbiAKMDAwMDAxMzcxNSAwMDAwMCBuIAowMDAwMDEzODI0IDAwMDAwIG4gCjAwMDAwMTM5 MjkgMDAwMDAgbiAKdHJhaWxlcgo8PAovU2l6ZSA0NwovUm9vdCAyIDAgUgovSW5mbyA0IDAg UgovSUQgWzxFNTI3REE2Q0Q1MjE3QkQ1QkE3OTQxNjAyMUFCMjI2OT4gPEU1MjdEQTZDRDUy MTdCRDVCQTc5NDE2MDIxQUIyMjY5Pl0KPj4Kc3RhcnR4cmVmCjE0NDUyCiUlRU9GCg== --Boundary_(ID_If8Jz47Rnb/tCFmjmveaAw)-- From john.fischer@oracle.com Mon May 10 13:42:05 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o47I0Yg0029658 for ; Fri, 7 May 2010 11:00:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o47I0WxL027891; Fri, 7 May 2010 11:00:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L220092RA0WMN00@nwk-avmta-2.sfbay.sun.com>; Fri, 07 May 2010 11:00:32 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L22004IKA0SJ650@nwk-avmta-2.sfbay.sun.com>; Fri, 07 May 2010 11:00:29 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o47I0Sp2006743; Fri, 07 May 2010 18:00:28 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o47C9brC016209; Fri, 07 May 2010 18:00:23 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 223589031273255209; Fri, 07 May 2010 11:00:09 -0700 Received: from [10.7.250.1] (/10.7.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 May 2010 11:00:08 -0700 Date: Fri, 07 May 2010 11:00:07 -0700 From: John Fischer Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BDEFF73.5030404@oracle.com> To: Doug Leavitt Cc: "Laszlo (Laca) Peter" , Brian Cameron , Albert Lee , Sebastien Roy , PSARC-ext Message-id: <4BE45527.4080500@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_If8Jz47Rnb/tCFmjmveaAw)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE45538.019D:SCFMA4539814,ss=1,vtr=str,vl=0,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 23600 This is a multi-part message in MIME format. --Boundary_(ID_If8Jz47Rnb/tCFmjmveaAw) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Doug, Does the attached document satisfy this request for additional documentation? Laca, if not please provide what Doug is requesting. I will extend the timer for another few days to address the request. Thanks, John On 05/ 3/10 09:53 AM, Doug Leavitt wrote: > In addition to the missing definitions for the > Meta(*.*), SUNW*, and IPS* keys commonly deployed > in pkgbuils spec files today, I also noticed that neither > the proposal or the case materials make any reference to > > %include Solaris.inc > > or any of the include files Solaris.inc ifself includes and > that are generally expected as part of current pkgbuild > spec files, > > > I believe that this ARC case needs to at least document > and (hopefully) set some level of commitment to the > well defined tag list. > > At a minimum this: > http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/specdesc > > needs to be included in the ARC materials. > > But, I'm sure better documentation than above > should be provided. Say perhaps a man page or two? > > Doug. > > > > On 05/ 1/10 02:16 AM, Brian Cameron wrote: >> Albert: >> >>>>> The spec file syntax is also conceptually an exported interface, >>>>> and it >>>>> needs a stability level. It would be nice if the spec file syntax >>>>> were >>>>> part of the materials (I'm guessing it's documented somewhere >>>>> anyway). >>> The basic syntax is the same as rpmbuild spec files, and pkgbuild >>> includes >>> a set of predefined macros and supports some additional tags >>> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php >> True, although pkgbuild does support some Solaris/OpenSolaris specific >> extensions, and it might be good to highlight those a bit more. >> >> For example, one thing I notice is that the new "IPS_package_name" >> and "Meta(info.classification)" keys cause syntax errors if you try >> to use an older version of pkgbuild. It would be nice if pkgbuild >> had better backwards compatibility support and provided some mechanism >> to allow people who just want to build SVR5 packages a way to tell >> pkgbuild to ignore keys that provide features that are not going to be >> used anyway. >> >> Brian >> --Boundary_(ID_If8Jz47Rnb/tCFmjmveaAw) Content-type: application/pdf; name=specdesc.pdf Content-transfer-encoding: base64 Content-disposition: attachment; filename=specdesc.pdf JVBERi0xLjQKJaqrrK0KNCAwIG9iago8PAovQ3JlYXRvciAoQXBhY2hlIEZPUCBWZXJzaW9u IHN2bi10cnVuaykKL1Byb2R1Y2VyIChBcGFjaGUgRk9QIFZlcnNpb24gc3ZuLXRydW5rKQov Q3JlYXRpb25EYXRlIChEOjIwMTAwNTA3MTc1NzEyWikKPj4KZW5kb2JqCjUgMCBvYmoKPDwK ICAvTiAzCiAgL0xlbmd0aCAxMSAwIFIKICAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl YW0KeJydlndUU9kWh8+9N71QkhCKlNBraFICSA29SJEuKjEJEErAkAAiNkRUcERRkaYIMijg gKNDkbEiioUBUbHrBBlE1HFwFBuWSWStGd+8ee/Nm98f935rn73P3Wfvfda6AJD8gwXCTFgJ gAyhWBTh58WIjYtnYAcBDPAAA2wA4HCzs0IW+EYCmQJ82IxsmRP4F726DiD5+yrTP4zBAP+f lLlZIjEAUJiM5/L42VwZF8k4PVecJbdPyZi2NE3OMErOIlmCMlaTc/IsW3z2mWUPOfMyhDwZ y3PO4mXw5Nwn4405Er6MkWAZF+cI+LkyviZjg3RJhkDGb+SxGXxONgAoktwu5nNTZGwtY5Io MoIt43kA4EjJX/DSL1jMzxPLD8XOzFouEiSniBkmXFOGjZMTi+HPz03ni8XMMA43jSPiMdiZ GVkc4XIAZs/8WRR5bRmyIjvYODk4MG0tbb4o1H9d/JuS93aWXoR/7hlEH/jD9ld+mQ0AsKZl tdn6h21pFQBd6wFQu/2HzWAvAIqyvnUOfXEeunxeUsTiLGcrq9zcXEsBn2spL+jv+p8Of0Nf fM9Svt3v5WF485M4knQxQ143bmZ6pkTEyM7icPkM5p+H+B8H/nUeFhH8JL6IL5RFRMumTCBM lrVbyBOIBZlChkD4n5r4D8P+pNm5lona+BHQllgCpSEaQH4eACgqESAJe2Qr0O99C8ZHA/nN i9GZmJ37z4L+fVe4TP7IFiR/jmNHRDK4ElHO7Jr8WgI0IABFQAPqQBvoAxPABLbAEbgAD+AD AkEoiARxYDHgghSQAUQgFxSAtaAYlIKtYCeoBnWgETSDNnAYdIFj4DQ4By6By2AE3AFSMA6e gCnwCsxAEISFyBAVUod0IEPIHLKFWJAb5AMFQxFQHJQIJUNCSAIVQOugUqgcqobqoWboW+go dBq6AA1Dt6BRaBL6FXoHIzAJpsFasBFsBbNgTzgIjoQXwcnwMjgfLoK3wJVwA3wQ7oRPw5fg EVgKP4GnEYAQETqiizARFsJGQpF4JAkRIauQEqQCaUDakB6kH7mKSJGnyFsUBkVFMVBMlAvK HxWF4qKWoVahNqOqUQdQnag+1FXUKGoK9RFNRmuizdHO6AB0LDoZnYsuRlegm9Ad6LPoEfQ4 +hUGg6FjjDGOGH9MHCYVswKzGbMb0445hRnGjGGmsVisOtYc64oNxXKwYmwxtgp7EHsSewU7 jn2DI+J0cLY4X1w8TogrxFXgWnAncFdwE7gZvBLeEO+MD8Xz8MvxZfhGfA9+CD+OnyEoE4wJ roRIQiphLaGS0EY4S7hLeEEkEvWITsRwooC4hlhJPEQ8TxwlviVRSGYkNimBJCFtIe0nnSLd Ir0gk8lGZA9yPFlM3kJuJp8h3ye/UaAqWCoEKPAUVivUKHQqXFF4pohXNFT0VFysmK9YoXhE cUjxqRJeyUiJrcRRWqVUo3RU6YbStDJV2UY5VDlDebNyi/IF5UcULMWI4kPhUYoo+yhnKGNU hKpPZVO51HXURupZ6jgNQzOmBdBSaaW0b2iDtCkVioqdSrRKnkqNynEVKR2hG9ED6On0Mvph +nX6O1UtVU9Vvuom1TbVK6qv1eaoeajx1UrU2tVG1N6pM9R91NPUt6l3qd/TQGmYaYRr5Grs 0Tir8XQObY7LHO6ckjmH59zWhDXNNCM0V2ju0xzQnNbS1vLTytKq0jqj9VSbru2hnaq9Q/uE 9qQOVcdNR6CzQ+ekzmOGCsOTkc6oZPQxpnQ1df11Jbr1uoO6M3rGelF6hXrtevf0Cfos/ST9 Hfq9+lMGOgYhBgUGrQa3DfGGLMMUw12G/YavjYyNYow2GHUZPTJWMw4wzjduNb5rQjZxN1lm 0mByzRRjyjJNM91tetkMNrM3SzGrMRsyh80dzAXmu82HLdAWThZCiwaLG0wS05OZw2xljlrS LYMtCy27LJ9ZGVjFW22z6rf6aG1vnW7daH3HhmITaFNo02Pzq62ZLde2xvbaXPJc37mr53bP fW5nbse322N3055qH2K/wb7X/oODo4PIoc1h0tHAMdGx1vEGi8YKY21mnXdCO3k5rXY65vTW 2cFZ7HzY+RcXpkuaS4vLo3nG8/jzGueNueq5clzrXaVuDLdEt71uUnddd457g/sDD30PnkeT x4SnqWeq50HPZ17WXiKvDq/XbGf2SvYpb8Tbz7vEe9CH4hPlU+1z31fPN9m31XfKz95vhd8p f7R/kP82/xsBWgHcgOaAqUDHwJWBfUGkoAVB1UEPgs2CRcE9IXBIYMj2kLvzDecL53eFgtCA 0O2h98KMw5aFfR+OCQ8Lrwl/GGETURDRv4C6YMmClgWvIr0iyyLvRJlESaJ6oxWjE6Kbo1/H eMeUx0hjrWJXxl6K04gTxHXHY+Oj45vipxf6LNy5cDzBPqE44foi40V5iy4s1licvvj4EsUl nCVHEtGJMYktie85oZwGzvTSgKW1S6e4bO4u7hOeB28Hb5Lvyi/nTyS5JpUnPUp2Td6ePJni nlKR8lTAFlQLnqf6p9alvk4LTduf9ik9Jr09A5eRmHFUSBGmCfsytTPzMoezzLOKs6TLnJft XDYlChI1ZUPZi7K7xTTZz9SAxESyXjKa45ZTk/MmNzr3SJ5ynjBvYLnZ8k3LJ/J9879egVrB XdFboFuwtmB0pefK+lXQqqWrelfrry5aPb7Gb82BtYS1aWt/KLQuLC98uS5mXU+RVtGaorH1 futbixWKRcU3NrhsqNuI2ijYOLhp7qaqTR9LeCUXS61LK0rfb+ZuvviVzVeVX33akrRlsMyh bM9WzFbh1uvb3LcdKFcuzy8f2x6yvXMHY0fJjpc7l+y8UGFXUbeLsEuyS1oZXNldZVC1tep9 dUr1SI1XTXutZu2m2te7ebuv7PHY01anVVda926vYO/Ner/6zgajhop9mH05+x42Rjf2f836 urlJo6m06cN+4X7pgYgDfc2Ozc0tmi1lrXCrpHXyYMLBy994f9Pdxmyrb6e3lx4ChySHHn+b +O31w0GHe4+wjrR9Z/hdbQe1o6QT6lzeOdWV0iXtjusePhp4tLfHpafje8vv9x/TPVZzXOV4 2QnCiaITn07mn5w+lXXq6enk02O9S3rvnIk9c60vvG/wbNDZ8+d8z53p9+w/ed71/LELzheO XmRd7LrkcKlzwH6g4wf7HzoGHQY7hxyHui87Xe4Znjd84or7ldNXva+euxZw7dLI/JHh61HX b95IuCG9ybv56Fb6ree3c27P3FlzF3235J7SvYr7mvcbfjT9sV3qID0+6j068GDBgztj3LEn P2X/9H686CH5YcWEzkTzI9tHxyZ9Jy8/Xvh4/EnWk5mnxT8r/1z7zOTZd794/DIwFTs1/lz0 /NOvm1+ov9j/0u5l73TY9P1XGa9mXpe8UX9z4C3rbf+7mHcTM7nvse8rP5h+6PkY9PHup4xP n34D94Tz+wplbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKWy9JQ0NCYXNlZCA1IDAgUl0KZW5k b2JqCjcgMCBvYmoKPDwKICAvVHlwZSAvTWV0YWRhdGEKICAvU3VidHlwZSAvWE1MCiAgL0xl bmd0aCAxMiAwIFIKPj4Kc3RyZWFtCjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1w Q2VoaUh6cmVTek5UY3prYzlkIj8+Cgo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1l dGEvIj4KPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIy LXJkZi1zeW50YXgtbnMjIj4KPHJkZjpEZXNjcmlwdGlvbiB4bWxuczpkYz0iaHR0cDovL3B1 cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iIHJkZjphYm91dD0iIj4KPGRjOmRhdGU+CjxyZGY6 U2VxPgo8cmRmOmxpPjIwMTAtMDUtMDdUMTc6NTc6MTJaPC9yZGY6bGk+CjwvcmRmOlNlcT4K PC9kYzpkYXRlPgo8L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiB4bWxuczpw ZGY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8iIHJkZjphYm91dD0iIj4KPHBkZjpQ REZWZXJzaW9uPjEuNDwvcGRmOlBERlZlcnNpb24+CjxwZGY6UHJvZHVjZXI+QXBhY2hlIEZP UCBWZXJzaW9uIHN2bi10cnVuazwvcGRmOlByb2R1Y2VyPgo8L3JkZjpEZXNjcmlwdGlvbj4K PHJkZjpEZXNjcmlwdGlvbiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC8iIHJkZjphYm91dD0iIj4KPHhtcDpDcmVhdGVEYXRlPjIwMTAtMDUtMDdUMTc6NTc6MTJa PC94bXA6Q3JlYXRlRGF0ZT4KPHhtcDpDcmVhdG9yVG9vbD5BcGFjaGUgRk9QIFZlcnNpb24g c3ZuLXRydW5rPC94bXA6Q3JlYXRvclRvb2w+Cjx4bXA6TWV0YWRhdGFEYXRlPjIwMTAtMDUt MDdUMTc6NTc6MTJaPC94bXA6TWV0YWRhdGFEYXRlPgo8L3JkZjpEZXNjcmlwdGlvbj4KPC9y ZGY6UkRGPgo8L3g6eG1wbWV0YT4KPD94cGFja2V0IGVuZD0iciI/PgoKCmVuZHN0cmVhbQpl bmRvYmoKMTAgMCBvYmoKPDwgL0xlbmd0aCAxMyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCnicbY/LTgMxDEX3+QovYUHGjzzsLhHtgt2I7BALNAxopE5boP8vrHakthKK kij35h7bBOjrgfzQRFFVrVbMMMzhO9DJJKjslyu9a/2Vnlki13wxrwK1mNPsP4dv6b5PAISv 8NhCt6lACu1z+eC9UUqREpkpG3jBSMhmRQXaDK93L4dxgM20HeFp/B1+psNx2u/u36A9OyyD 3bCYUhQtZpL8YRxrQdMiC+v9Y56W7KW8SazZELkYCErMhRBTSecII1pH2HEB4pXQOb1uPncf /gDCQEorCmVuZHN0cmVhbQplbmRvYmoKOCAwIG9iago8PAogIC9SZXNvdXJjZXMgMyAwIFIK ICAvVHlwZSAvUGFnZQogIC9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCiAgL0JsZWVkQm94IFsw IDAgNTk1IDg0Ml0KICAvVHJpbUJveCBbMCAwIDU5NSA4NDJdCiAgL1BhcmVudCAxIDAgUgog IC9Db250ZW50cyAxMCAwIFIKPj4KCmVuZG9iagoxMSAwIG9iagoyNTk2CmVuZG9iagoxMiAw IG9iago4MzAKZW5kb2JqCjEzIDAgb2JqCjIxMgplbmRvYmoKMTUgMCBvYmoKPDwgL1VSSSAo ZmlsZTovb3B0L29zby94d2lraS90ZW1wL3h3aWtpL2R5aFVsM09mL0NvbW11bml0eSUyMEdy b3VwJTIwc3clMkRwb3J0ZXJzLnNwZWNkZXNjLnRtcGwuc3BlYy50eHQpCi9TIC9VUkkgPj4K ZW5kb2JqCjE2IDAgb2JqCjw8IC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb IDI1OC40NjIgNzE1Ljk3OSAzMjEuOTQ4IDcyNC4wNzkgXQovQyBbIDAgMCAwIF0KL0JvcmRl ciBbIDAgMCAwIF0KL0EgMTUgMCBSCi9IIC9JCgo+PgplbmRvYmoKMTggMCBvYmoKPDwgL1VS SSAoZmlsZTovb3B0L29zby94d2lraS90ZW1wL3h3aWtpL2R5aFVsM09mL0NvbW11bml0eSUy MEdyb3VwJTIwc3clMkRwb3J0ZXJzLnNwZWNkZXNjLm5hbm8uc3BlYy50eHQpCi9TIC9VUkkg Pj4KZW5kb2JqCjE5IDAgb2JqCjw8IC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbIDk2LjAgMTY3LjM5MyAxNDUuOTg2IDE3NS40OTMgXQovQyBbIDAgMCAwIF0KL0JvcmRl ciBbIDAgMCAwIF0KL0EgMTggMCBSCi9IIC9JCgo+PgplbmRvYmoKMjAgMCBvYmoKPDwgL0xl bmd0aCAyMSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnicnVhZb9tGEH73 r1ggMJAW9Zp7cw20D2maHkjapHbSBzkIaGols+VVkmprBPnv/ZaHSImUU1SGD1Ez3xw7882s GQnwdcHwI5SMhmFojQkUibOzP89Y+yEjhuMXngRke/bs5uzyhSIsIDebXgDajBkaam2tNoZI SYUIgoCFgtxkZPX02yLLdnnSPJDvq2JXkvrvi7KoGlfV5IJcly4mL5LUkeeujqukbJIi/+I9 ufnp7Lubszdw483EFcUF5UZ1/rw59NFoiwDs5zwNaSg43DOCCH7k6eto60hnfNSQATUGGoKZ uYaYSatHpBFvGtUNyYp1skncmtw9kGidJTkpcgIle8mCS64J41eCHSRhGic/CNEQJqg6CBKC DGmyMM3DzvIjaW4hAqrEEYYQVHKfKeT0CMP/hQDiaIqiiD1CUIxaZbpcd/H/4CpHkpo0947E u6pyeUNKl6+TfEuifE3iIm+q5I5UrizqpCmqh9lxhJJyBreU5gsGOukuV9V2qqap1KfUah/Z xkfWuKxMo8btk79X1Cg+GjKG4yQaqQk1CSiXEr6SzbTiDrPApaVWGmtDtNUpf0dp2GD2lDQd Um2JodIcZVuH1BoJVf+JF39yBB4QY6gVKAtu+yN9QsbQN0VFyij+Az1wRVblH1uSR5l7PwNB QqxHsGF4yo5VIx30dm7uceytHX/OUZr2TdDVUN09Xa+T7l1TtCVSVkndJLmbGWCBRBv7sxgK /MngO4lwILt87aoWokYMJE1il9f4qKu8QTJpapdu6BwdHWWsTyU7mUrGOTXK51Lvc5nkcbpb u9qHtkvd7dP69os+lZMn84wywajhYAq09ilzKCOtEHBg+4DPe2vkukgj5Ini/VxNG6pMaFGB qlP7Gfm4IuPrkYNmRlMl/UnzPg3XuyyLqoe9/qq+B5GT9UgpCyihoipAGQvTe/4OzA/RqwMX /uoeLuhbiVoPrBWB7PRfdqc56g/H2zyUjtw+TRwl379++Rf/ijy7fk4pXco5D9DDAmdslO5g 31bpNDFktatSX4gFCIrUxa6KfUEWv7u4WYBj4HrryyEYGLfVuJrBxUVWVq6uwf5NVN2hExbQ OKNCoyC06ovrORoBxLhrusT9Ap/6c58ri4AKVKVVoRoSnq+LanRlok32w3kBx1JufcmJ/vif 7ZJ0/WtRND3U+ccPTVaWUXP/6fL8oy+iTxfnH/uT/HRx58XnsDKkXKkgkAN/XL/9+bcPzyJk JGmdBOxd9+7TXFsZ0L8vaCYn2t8W5UOVbO/hWe8IjYdHcwyjKJOmm9GHvbR2m2iXNhdr56fS YktxDCBMATSFFNO0uD93Cc4V/d7GTXxRdzAujxOQwu3T63eV3JOP93KRDbgVNDAK1MZZZ2CC Xe3yJgGj/W90gdWgHQAj2RzUw4+vr8nrHuRVlCcbh33lReLS9bzSBMNs0yZgQV9or1wTof/y TUF3JQrWRZlnwGlTeceIy6IkJcVmqbdI6iKQ94LnHANOIPHW6Jk5AOYNvl11YPDIXFLWbea6 9fNyVFqwJrDSYgaENmAza+N68gFdvbe4moYTF6inUXDBgtQ09BMkNHZmIcaeWO/H42hhiODw 8wVwLakJtQ2H3eF8fbz3TaUNBp6fLmZgr1Va5NvHiV1YRjVmSzgQ6Dl4rZyJySCgWoLL1EAj K8h15ODJMMPkr+foEou6Mixgsu/z82U6kRwTToBOhO7dWH0WGju6BLsyPrZ/3YCI55IKs4eD KZjtK3zViz4GbzAKQHCeI3r8GDU9z7oMwfKs3dL7GFetIK5Ij6BbsLInLztsPud+q5o3pwrA s96HUA3o7fq19Xewbt8qXZUltSfrBUOKa8pEfx/sw7iP8q1Li+1cWIBSAxFwI/ahtMIE0sT5 pd4NNk7dNxRKFhWIuaXZ8YXju38i7OVDlIt3jZBjWYEHduim7rLht8G68Iz5+DVj3INdb+t4 L2RYOVFnqLSQaBT1obVbztWpyweOd66QR3kxWt3fN1pZ1IXVFq3rLw8nLhrLSdTYHAKNJArW t4Mn9D2RY/8Yk/oqKktk5HRONTYAfXCqBxc4jzzMm2xiYUxl1ln4zL1FaYoLljVM9xX9pac4 2lL39PX1N6TdXmfVpzVWTJwNx9VpilB36+oBwrDCzkGMxAmB7RkXA8iE//4jSIi7OPN3fmkH kINx6OdFD/L215cLAJYjQ+BtOyzsPUA3VQb1zotuw5z8n+BfUMqcSAplbmRzdHJlYW0KZW5k b2JqCjE3IDAgb2JqClsKMTYgMCBSCjE5IDAgUgpdCmVuZG9iagoxNCAwIG9iago8PAogIC9S ZXNvdXJjZXMgMyAwIFIKICAvVHlwZSAvUGFnZQogIC9NZWRpYUJveCBbMCAwIDU5NSA4NDJd CiAgL0JsZWVkQm94IFswIDAgNTk1IDg0Ml0KICAvVHJpbUJveCBbMCAwIDU5NSA4NDJdCiAg L1BhcmVudCAxIDAgUgogIC9Bbm5vdHMgMTcgMCBSCiAgL0NvbnRlbnRzIDIwIDAgUgo+PgoK ZW5kb2JqCjIxIDAgb2JqCjE2NzEKZW5kb2JqCjIzIDAgb2JqCjw8IC9MZW5ndGggMjQgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4nJVW227cNhB991cMAhRNAi+XpC4U jdQPTesWRdM2tYs8NEUgS9xdIZKoiNo47tf3UNr1XiR7UxqWDVE8nDlz5iKI42cm8EhCwZIk 0UrxiLLq7NOZ6DcFKYk/eMNpefb9zdn8KiLB6Wax+QCnhVAsiWOtY6UoDFkQcM5FEtBNRX8/ f22ral0X3T391Np1Q+5u1ti2M62jGV03JqOrojT0g3FZWzRdYesX/9DNL2c/3py9hRlv90yJ ZMCkigZ73h7aqGINB/QpSxOWBBLmqYACeWTpH+nS0HD57kTImVI4EQg1PhGOvo6e+Br+lqnr qLJ5sShMTrf3lOZVUZOtCYf0XPC5jEnIi0AckLDvpzxwUZNioTpwklPMZBhqrUFHf/FLKuqF ZRlud7g5Sz3LRN9d0hvTpe+fT+y+f3HkGq6PmOQJYONgC1sWmamdoe6+MbRdgP11eH8xwpAh E8qTEoTHGAuvgj2M679+e/fhtW3u22K56sZQQcBEoEAvDw+8XDeua01a7UHtebndnfAvlEwA jQt1CFilRd3h17RTgLvdCchIMB4jEsmOsv5Qaxrris629x/WbXkMebg7ARtzxqWPRPAA23xc shwQIDEfMPctPd7dYs6vFFKERcGRgJKEARt2CzFcsMvTPx+M20JEpI+OCw5RxtpTqTbSf2co bQ28p25lqGltZpwju6DcLIq6qJd4XzhGP5t2+NLZCp/nJnWMse1Vk2oXEFWYoPzoaGMtEc7M XyHP1qW5ZM4b36/ZJfl4Uf+mF9z752uHTFzYlm7XRZnDkrHwIbUwgjJCvs3kx9bvjamvbZm2 haPMVg1y6Ra3NGn2EcXFjaEhulBAIYHU+7bfps7MvJXu0I2JpBQsUNCCSp4yDY47S1laQgD0 zKP3HLhn59T7j0qEuIzRobQgRL7KQJ7w/JBXBzY7qs1nJE1Rf7YfTT4BrlnAkcFxEp4Az4vW ZF15P8ZQCToCR03iB/yB+GxlduTNXtU1HvmuyVwyFOHFGDBRTAYRKlQsThK6bjODMOd4rNIa 8T3fChx6qqDuMbyOmdDIjEicktKsEYS+2TcKb+pYPJJHTMRS6zB4MvhYWx4uqE6RV8g7b+Xw 8pwMW7IxukCtlvGuizwKPqxljYydNWltyjEWGjfXwpf9UzrygbogOcuLZdFRH0eq19Wtac9R KzA2oF9OJBIEyniERJLxKS6G5f23bd7rk+5WBa7pK9MgHF+CJpoXyrnwuSa+jpK0aUofvs72 2INgJmwPNdNJ4Mvlk5rz7Owr+KJH3Q/oQFdRj6+IUNFRkjXX6utMh67XTdkj34En95hKYsW0 8H1TnUriYa1Q02duZe9mdyaFze0YUsUswZS3l85FnZXr3MxfMvxHQ/Y9lPBFmy4rU3eOvtl8 920+yUESYfhLoGfMWP+rmA2+06awexvG4DpkCUcM9a5HeMuz7QCzq+MPr8YjDQ+Y8oN0Ip8U GNx/ABksHEMJyTBoaRB5wKT50s02Opy/HKCsj8Kmah82QyTIpnWhLZ6P75CCxTryw/SprPaQ 5ktaeUVdv7kCwahsxnUThgecxRGSDI99w3Gi8S10vuNgr9n2vdIPrx55nZbUTLZbzDQsllIn 0a7l9O3CzizA3AA2fxS8tGihxb/9hOwwO1QYYnDR+J4wYVGC1hbFp5jBuJ2Wdum2I1k/8f8H Xrlb0gplbmRzdHJlYW0KZW5kb2JqCjIyIDAgb2JqCjw8CiAgL1Jlc291cmNlcyAzIDAgUgog IC9UeXBlIC9QYWdlCiAgL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KICAvQmxlZWRCb3ggWzAg MCA1OTUgODQyXQogIC9UcmltQm94IFswIDAgNTk1IDg0Ml0KICAvUGFyZW50IDEgMCBSCiAg L0NvbnRlbnRzIDIzIDAgUgo+PgoKZW5kb2JqCjI0IDAgb2JqCjEyNjgKZW5kb2JqCjI2IDAg b2JqCjw8IC9UeXBlIC9BY3Rpb24KL1MgL0dvVG8KL0QgWzE0IDAgUiAvWFlaIDcyLjAgNzY5 Ljg4OSBudWxsXQo+PgplbmRvYmoKMjcgMCBvYmoKPDwgL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFsgNzguMCA2ODcuNjM5IDE1Ny42MzQgNjk1LjczOSBdCi9DIFsgMCAw IDAgXQovQm9yZGVyIFsgMCAwIDAgXQovQSAyNiAwIFIKL0ggL0kKCj4+CmVuZG9iagoyOSAw IG9iago8PCAvVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWyA1MTguNjY0IDY4 Ny42MzkgNTIzLjE2NCA2OTUuNzM5IF0KL0MgWyAwIDAgMCBdCi9Cb3JkZXIgWyAwIDAgMCBd Ci9BIDI2IDAgUgovSCAvSQoKPj4KZW5kb2JqCjMwIDAgb2JqCjw8IC9UeXBlIC9BY3Rpb24K L1MgL0dvVG8KL0QgWzE0IDAgUiAvWFlaIDcyLjAgNzUzLjY4OSBudWxsXQo+PgplbmRvYmoK MzEgMCBvYmoKPDwgL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsgODQuMCA2 NzYuODM5IDE2OS4wOTMgNjg0LjkzOSBdCi9DIFsgMCAwIDAgXQovQm9yZGVyIFsgMCAwIDAg XQovQSAzMCAwIFIKL0ggL0kKCj4+CmVuZG9iagozMiAwIG9iago8PCAvVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWyA1MTguNjYzIDY3Ni44MzkgNTIzLjE2MyA2ODQuOTM5 IF0KL0MgWyAwIDAgMCBdCi9Cb3JkZXIgWyAwIDAgMCBdCi9BIDMwIDAgUgovSCAvSQoKPj4K ZW5kb2JqCjMzIDAgb2JqCjw8IC9UeXBlIC9BY3Rpb24KL1MgL0dvVG8KL0QgWzE0IDAgUiAv WFlaIDcyLjAgMjIzLjEwMyBudWxsXQo+PgplbmRvYmoKMzQgMCBvYmoKPDwgL1R5cGUgL0Fu bm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsgODQuMCA2NjYuMDM5IDE1Ny4xNjMgNjc0LjEz OSBdCi9DIFsgMCAwIDAgXQovQm9yZGVyIFsgMCAwIDAgXQovQSAzMyAwIFIKL0ggL0kKCj4+ CmVuZG9iagozNSAwIG9iago8PCAvVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WyA1MTguNjYyIDY2Ni4wMzkgNTIzLjE2MiA2NzQuMTM5IF0KL0MgWyAwIDAgMCBdCi9Cb3Jk ZXIgWyAwIDAgMCBdCi9BIDMzIDAgUgovSCAvSQoKPj4KZW5kb2JqCjM2IDAgb2JqCjw8IC9U eXBlIC9BY3Rpb24KL1MgL0dvVG8KL0QgWzE0IDAgUiAvWFlaIDcyLjAgMTY2LjA0MyBudWxs XQo+PgplbmRvYmoKMzcgMCBvYmoKPDwgL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFsgODQuMCA2NTUuMjM5IDIxNC42MTUgNjYzLjMzOSBdCi9DIFsgMCAwIDAgXQovQm9y ZGVyIFsgMCAwIDAgXQovQSAzNiAwIFIKL0ggL0kKCj4+CmVuZG9iagozOCAwIG9iago8PCAv VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWyA1MTguNSA2NTUuMjM5IDUyMy4w IDY2My4zMzkgXQovQyBbIDAgMCAwIF0KL0JvcmRlciBbIDAgMCAwIF0KL0EgMzYgMCBSCi9I IC9JCgo+PgplbmRvYmoKMzkgMCBvYmoKPDwgL1R5cGUgL0FjdGlvbgovUyAvR29UbwovRCBb MjIgMCBSIC9YWVogNzIuMCA2OTguMTc3IG51bGxdCj4+CmVuZG9iago0MCAwIG9iago8PCAv VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWyA4NC4wIDY0NC40MzkgMTYxLjE0 NiA2NTIuNTM5IF0KL0MgWyAwIDAgMCBdCi9Cb3JkZXIgWyAwIDAgMCBdCi9BIDM5IDAgUgov SCAvSQoKPj4KZW5kb2JqCjQxIDAgb2JqCjw8IC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu awovUmVjdCBbIDUxOC42NjMgNjQ0LjQzOSA1MjMuMTYzIDY1Mi41MzkgXQovQyBbIDAgMCAw IF0KL0JvcmRlciBbIDAgMCAwIF0KL0EgMzkgMCBSCi9IIC9JCgo+PgplbmRvYmoKNDIgMCBv YmoKPDwgL0xlbmd0aCA0MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnic lZ1Lb1zHEUb3/BV3aS806nr0o7KMIwcJEMCKuQuyoCVKICA+ItJI9O/TNdSDM8MofWDAj3Hd mjMz1D2357vFlq3Mv17I/Ntw2Y0xovdStzfXZ/86k/3/lK3r/Md8pGzvz/54fvby57pJ2c7f fS6YR4v03WgtovW+ue/MSikybDu/3v7xw0+319e/31w9fNr+/PH297vt/t8v7m4/Plx+vN9e bL/eXb7Zfr76cLn96fL+zceru4er25sf/7md//Xs1fnZ64nx+glKVdtpr488rw8Ze4v5AuL/ kY7dMJ143TbTI9JfLt5fbo9P/u0IL7ve5xEm/fQIPamu36mer/fDxf3Ddn379urd1eXb7bdP 28Xb66ub7fZmmwfFSykvtW2ifzA5eBOevk49eIl9Uz94iWXz2GmViPlm7J/2/OK3+f7evtt+ ur15uLx5uH9snW9PHBzatlF2GvOD7KU/Hrv/fH7cXkTffth/TJ///eTT+tpk1F0zL0VbnLb7 cvjxMWPXa5/vWh+nx+yOikN28+NbLZ4/MOud666ud+6AWUoB0FIUUEtxgC2lIe4g3CKEW4xw SyXc88854NZCuFUJtzrh1o64g3CbEG4zwm2NcNsg3PMMDLhdCfc8XwNu74g7CHcVwl2dcNdG uOsg3K0Q7maEu1XC3TriDsLdlXB3J9y9Ee5OXCmDyHJeqBDuQXQpA/kykC8D+TKQLwP5Mogv tRBfaiG+1EJ8qYX4UoX4UoX4UoX4UoX4UoX4UpX4UpX4UpX4UpX4Uo34Uo34Uo34Uo34Uo34 Up34Up34Up34Up34UivxpVbiS63El7NycrcYo9pKdfpyubqlL9er05fr1Y1wt0G4uxDuboS7 V8LdO+EehXAPJdzDCfdoiDsIdwjhDiPcUQl3DMBtpQBuKwq4rTjgttIRdxBuEcItRrilEW4Z hFsL4VYl3FoJt3bEHYTbhHCbE25rhNsG4c7vX9d7uxFur4TbiS/NiS+tEl9aJb60SnxplfjS GvGlNeJLa8SX1ogvrRNfWie+tE58aZ340jrxpQ3iSxvElzaIL20gXwbyZSBfBvJlIF8G8aUX 4ksvxJdeiC+9EF+6EF+6EF+6EF+6EF+6EF+6El+6El+6El+6El+6EV+6EV+6EV+6EV+6EV/6 9Hz1EqOKnFb/j5TR57K+NS9F/Jmk046/ytN90jgL5gH6WPM1DfV9Vv4kEv3yQFZcvbt6c/FM MprnkphrAbVnWh90OUaZ6wdJ2NFODzz5CnIuH+YrXS32XVvv3Hax3jkA81w6rDPPlcM68zyh rDPPdcM681w2rDPPVcM68zyZrDPPNQNgjsk8K5raQvVcMrRYr7ZJvV7dJvZ69SDcc8kAuF0J 91wyAO65ZCDcQbirEO65ZADcc8kAuOeSAXC3QrjnkgFwzyUD4J5LBsIdhHsuGQD3XDIA7rlk ANx9EO65ZADcc8kAuPPWINC7E+4ohDuUcIcT7miIOwB3Bobr3BkYrnNnYLjOnYEh4JZCuEUJ tzjhlo64iS8zMATcSnyZgSHgVuLLDAwBtxFfZmAIuI34MgNDwO3ElxkYAm4nvszAEHBX4ssM DAF3Jb7MwHB/ETvLVqrj8Sp2rbrp42XsYrU/XnsvVjfC3Qbh7kK4uxHuXgl374R7FMI9lHAP J9yjIe4g3CGEO4xwRyXcMQB3Bobr3BkYrnNnYLjOnYEh4Q7CLUK4xQi3NMItg3BrIdyqhFsr 4daOuINwmxBuc8JtjXDbINxeCLcb4fZKuJ34MgNDwF2JLzMwBNyV+DIDQ8DdiC8zMATcjfgy A0PA3YkvMzAE3J34MgNDwk18mYEh4B7ElxkYAu6BfBnIl4F8GciXgXwZxJcZGK5zZ2C4zp2B 4Tp3BoaAW4gvMzAE3EJ8mYEh4Sa+zMAQcCvxZQaGgFuJLzMwBNxGfJmBIeA24ssMDAF3BoZ1 zGofp9XfC98eU0ONcHvmyGdSQ5l/TEcW5QzovuhrbDgmQ21PYsMvD7z6z8X13YfL+6Nu85Qp LRPDIs+0PehwfOTY5ehpsVKfOfL43Zmnz1rXq3U3QO+6K6B3R9xBuPcV680zGwXkmY4CdCkD sc9zKGGfiyXCPs+ihH2eRhF7IPa5YCLs80xK2OeplLDPcylhn4smwj7PpoR9nk4J+zyfEva5 cCLsrojdHbHPsy5iD8ReBbFXQ+y1Iva5gCLsrSD2poi9OWKfiyjEHoi9C2LvhtjnQoqwd6RU GcipMpBUM0ol7ANpVQbzajCvBvNqMK8G8qoW5NWMVAF7ZqqAXQvyqhbk1YxVCbsgr6ogr6og r2a0StgVeVUVeVUVeTXjVcJuyKtqyKtqyKsZsRJ2R15VR15VR17NmJWwV+RVrcirWpFXM2ot HjF6j6Xy2M0V6nJ5m14F3ZvtOuneEHsbiL0XxN4VsfeK2Htn7IHYhyD24Yh9NMQ+BmKPgtjD EHtUxB6dsQdhz/gVsGf+CtitNMJuZSB2EcQuhtilInbpiF0LYldF7OqIXRtjD8RugtjNELtV xG4DsXtB7K6I3R2xO/JqZrKEvSKvWkVezViWsFfkVWvIq9aQVzOaJewNedUa8qp15NWMZwl7 R161jrxqA3k1I1rCPpBXbSCv2mBeDebVYF4N5tVAXs2oFrBnVgvYvSCvekFezbiWsAvyqgvy qgvyaka2hF2RV12RV12RVzO2JeyGvOqGvOqGvJrRLWJHXt2Htzrb23PV34tBH8NbmU9kzxz5 XHgr3wb19jV/+eXXfIL9t7n5BH+7uLl6d3n/cPDgw+3Bf37Je78+8CXvfdLl7u7q5v3x889r nya1lPlBnZIcNDg5cp4RxnxHm/npkSffkc6roGHL1XWeD9Z71/ytx+vVTrjnFRDhDsLdhHA3 I9zz6gdwt0G4eyHcXQn3vPIB3L0j7iDcQwj3vOoB3KMR7ryzYr133lmx3jvvrAC9K+HOOytA 7wDcOZa2zq15XwXo3QB3jqUB7rypYr133lMBelfCnXdUgN5BuPN+ivXeeTsF6N0Id95Msd47 76VY7523UoDexJc5lga4nfhSnfgyx9IAtxNfqhNfaiW+zLE0wF2JL7USX2ojvsyxNMDdiC+1 EV9qI77MsTTA3YkvtRNfaie+zLE0wD2IL3UQX+ogvsyxNMAdyJeBfBnIl0F8mWNp69xWiC+t EF/mWBrhJr40Ib40Ib7MsTTALcSXpsSXpsSXOZYGuJX40oz40oz4MsfSALcRX5oRX5oTX+ZY GuB24ktz4kurxJc5lga4K/GlVeJLq8SXOZYGuBvxpTXiS2vElzmWBrg78aV14kvrxJc5lga4 B/GlDeJLG8SXOZYGuAP5MpAvA/kykC+D+NIL8aUX4sscS1vnzrE0wC3Ely7ElzmWBriF+NKV +NKV+DLH0gC3El+6El+6EV/mWBrgNuJLN+JLd+LLg2TjuPh7X/hnsFFPD3ku0ZgXep6xh7T6 WPRtT79JavZ0Y7/PD/z98u72/urh9uOno3752ze8lTJN8kzjgx5HR+YWPV82Rjw98vh9yS16 dL26fdt0caF6/hiu987UCIBLbtJDuleCnkNjhD336QHd508TYc+dekj3ztgDsedmPaB77tZD ujfEnvv1gO65YQ/onjv2kO4VseeePaR7IPbctQd0z217SPeG2HPjHtC9FsSeW/eQ7hWx5+Y9 pHsg9ty+B3TP/XtI94bYcwcf0D238AHdcw8f0r0i9tzFB3TPbXxA94GkKgNZNXNRxM68Gsyr wbwazKuBvJpDY4BdC/Jq5qOAPYfGEDvyqgryamakhF2QV3NojLAr8mrmpIRdkVdzaAyxI69m VkrYDXk1h8YIuyGvqiOv5tAYYXfkVXXk1cxMCXtFXs2hMcJekVczNyXsDXk1h8YIe0NezeyU sHfk1RwaI+wdeTXzU8SOvJpDY4R9IK9mhkrYB/NqMK8G82owrwbzaiCvWkFezSwVsOfQGGDP oTHCLsirmacSdkFeNUFeNUFezUyVsCvyag6NEXZFXs1clbAb8moOjRF2Q17NbJWwO/JqDo0R dkdezXyVsFfk1RwaI+wVeTUzVsLekFdzaIywN+TVzFkRO/JqDo0R9o68mlkrYe/Iqzk0RtgH 8mrmrYR9IK/m0BhhD+bVYF4N5tVAXvWCvJq5K2DPoTHAnkNjiB15NbNXwi7Iqzk0RtgFeTXz V8KuyKs5NEbYFXk1M1jCbsirOTRG2A15NXNYwu7Iq/skdjphPyl2Uv29ZPPgF4SeHuqP5a/O z16f/Rez9NVjCmVuZHN0cmVhbQplbmRvYmoKMjggMCBvYmoKWwoyNyAwIFIKMjkgMCBSCjMx IDAgUgozMiAwIFIKMzQgMCBSCjM1IDAgUgozNyAwIFIKMzggMCBSCjQwIDAgUgo0MSAwIFIK XQplbmRvYmoKMjUgMCBvYmoKPDwKICAvUmVzb3VyY2VzIDMgMCBSCiAgL1R5cGUgL1BhZ2UK ICAvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQogIC9CbGVlZEJveCBbMCAwIDU5NSA4NDJdCiAg L1RyaW1Cb3ggWzAgMCA1OTUgODQyXQogIC9QYXJlbnQgMSAwIFIKICAvQW5ub3RzIDI4IDAg UgogIC9Db250ZW50cyA0MiAwIFIKPj4KCmVuZG9iago0MyAwIG9iagozMTk3CmVuZG9iago0 NCAwIG9iago8PAogIC9UeXBlIC9Gb250CiAgL1N1YnR5cGUgL1R5cGUxCiAgL0Jhc2VGb250 IC9UaW1lcy1Sb21hbgogIC9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nCj4+CgplbmRvYmoK NDUgMCBvYmoKPDwKICAvVHlwZSAvRm9udAogIC9TdWJ0eXBlIC9UeXBlMQogIC9CYXNlRm9u dCAvQ291cmllcgogIC9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nCj4+CgplbmRvYmoKNDYg MCBvYmoKPDwKICAvVHlwZSAvRm9udAogIC9TdWJ0eXBlIC9UeXBlMQogIC9CYXNlRm9udCAv VGltZXMtQm9sZAogIC9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nCj4+CgplbmRvYmoKMSAw IG9iago8PCAvVHlwZSAvUGFnZXMKL0NvdW50IDQKL0tpZHMgWzggMCBSIDI1IDAgUiAxNCAw IFIgMjIgMCBSIF0gPj4KZW5kb2JqCjIgMCBvYmoKPDwKICAvVHlwZSAvQ2F0YWxvZwogIC9Q YWdlcyAxIDAgUgogIC9NZXRhZGF0YSA3IDAgUgogIC9QYWdlTGFiZWxzIDkgMCBSCj4+Cgpl bmRvYmoKMyAwIG9iago8PAovRm9udCA8PAogIC9GNSA0NCAwIFIKICAvRjkgNDUgMCBSCiAg L0Y3IDQ2IDAgUgo+PgovUHJvY1NldCBbIC9QREYgL0ltYWdlQiAvSW1hZ2VDIC9UZXh0IF0K L0NvbG9yU3BhY2UgPDwKICAvRGVmYXVsdFJHQiA2IDAgUgo+Pgo+PgplbmRvYmoKOSAwIG9i ago8PCAvTnVtcyBbMCA8PCAvUCAoMSkgPj4KIDEgPDwgL1AgKDIpID4+CiAyIDw8IC9QICgz KSA+PgogMyA8PCAvUCAoNCkgPj4KXSA+PgoKZW5kb2JqCnhyZWYKMCA0NwowMDAwMDAwMDAw IDY1NTM1IGYgCjAwMDAwMTQwMzcgMDAwMDAgbiAKMDAwMDAxNDExNiAwMDAwMCBuIAowMDAw MDE0MjA4IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMDE1MSAwMDAwMCBu IAowMDAwMDAyODMzIDAwMDAwIG4gCjAwMDAwMDI4NjYgMDAwMDAgbiAKMDAwMDAwNDA3NCAw MDAwMCBuIAowMDAwMDE0MzU4IDAwMDAwIG4gCjAwMDAwMDM3ODYgMDAwMDAgbiAKMDAwMDAw NDI0MSAwMDAwMCBuIAowMDAwMDA0MjYyIDAwMDAwIG4gCjAwMDAwMDQyODIgMDAwMDAgbiAK MDAwMDAwNjYyNiAwMDAwMCBuIAowMDAwMDA0MzAyIDAwMDAwIG4gCjAwMDAwMDQ0MzUgMDAw MDAgbiAKMDAwMDAwNjU5MiAwMDAwMCBuIAowMDAwMDA0NTc1IDAwMDAwIG4gCjAwMDAwMDQ3 MDggMDAwMDAgbiAKMDAwMDAwNDg0NSAwMDAwMCBuIAowMDAwMDA2ODExIDAwMDAwIG4gCjAw MDAwMDgxNzYgMDAwMDAgbiAKMDAwMDAwNjgzMiAwMDAwMCBuIAowMDAwMDA4MzQ0IDAwMDAw IG4gCjAwMDAwMTM1MDkgMDAwMDAgbiAKMDAwMDAwODM2NSAwMDAwMCBuIAowMDAwMDA4NDQ1 IDAwMDAwIG4gCjAwMDAwMTM0MTkgMDAwMDAgbiAKMDAwMDAwODU4MiAwMDAwMCBuIAowMDAw MDA4NzIyIDAwMDAwIG4gCjAwMDAwMDg4MDIgMDAwMDAgbiAKMDAwMDAwODkzOSAwMDAwMCBu IAowMDAwMDA5MDc5IDAwMDAwIG4gCjAwMDAwMDkxNTkgMDAwMDAgbiAKMDAwMDAwOTI5NiAw MDAwMCBuIAowMDAwMDA5NDM2IDAwMDAwIG4gCjAwMDAwMDk1MTYgMDAwMDAgbiAKMDAwMDAw OTY1MyAwMDAwMCBuIAowMDAwMDA5Nzg5IDAwMDAwIG4gCjAwMDAwMDk4NjkgMDAwMDAgbiAK MDAwMDAxMDAwNiAwMDAwMCBuIAowMDAwMDEwMTQ2IDAwMDAwIG4gCjAwMDAwMTM2OTQgMDAw MDAgbiAKMDAwMDAxMzcxNSAwMDAwMCBuIAowMDAwMDEzODI0IDAwMDAwIG4gCjAwMDAwMTM5 MjkgMDAwMDAgbiAKdHJhaWxlcgo8PAovU2l6ZSA0NwovUm9vdCAyIDAgUgovSW5mbyA0IDAg UgovSUQgWzxFNTI3REE2Q0Q1MjE3QkQ1QkE3OTQxNjAyMUFCMjI2OT4gPEU1MjdEQTZDRDUy MTdCRDVCQTc5NDE2MDIxQUIyMjY5Pl0KPj4Kc3RhcnR4cmVmCjE0NDUyCiUlRU9GCg== --Boundary_(ID_If8Jz47Rnb/tCFmjmveaAw)-- From john.fischer@oracle.com Wed May 12 05:47:21 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4CClLu3002679 for ; Wed, 12 May 2010 05:47:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4CCl7Ss002066; Wed, 12 May 2010 05:47:19 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2B00F0R4UVYX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 May 2010 05:47:19 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2B00MEB4UTK9F0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 May 2010 05:47:17 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4CClHip016372; Wed, 12 May 2010 12:47:17 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4C8T9Ph011441; Wed, 12 May 2010 12:47:12 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 258211711273668394; Wed, 12 May 2010 05:46:34 -0700 Received: from [10.7.250.1] (/10.7.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 May 2010 05:46:33 -0700 Date: Wed, 12 May 2010 05:46:32 -0700 From: John Fischer Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BE45527.4080500@oracle.com> To: Doug Leavitt Cc: "Laszlo (Laca) Peter" , Brian Cameron , Albert Lee , Sebastien Roy , PSARC-ext Message-id: <4BEAA328.9030503@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BEAA351.0056:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <4BE45527.4080500@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 2682 All, I am extending the timer to Friday, May 14th, to allow Laca to complete his document on the spec files. I'll keep extending the timer until the document is done. He has shown me the document that he is producing and it will resolve this need spec. Therefore, when it is completed and available in the archives I will close the case as approved. Thanks, John On 05/ 7/10 11:00 AM, John Fischer wrote: > Doug, > > Does the attached document satisfy this request > for additional documentation? > > Laca, if not please provide what Doug is requesting. > I will extend the timer for another few days to address > the request. > > Thanks, > > John > > > On 05/ 3/10 09:53 AM, Doug Leavitt wrote: >> In addition to the missing definitions for the >> Meta(*.*), SUNW*, and IPS* keys commonly deployed >> in pkgbuils spec files today, I also noticed that neither >> the proposal or the case materials make any reference to >> >> %include Solaris.inc >> >> or any of the include files Solaris.inc ifself includes and >> that are generally expected as part of current pkgbuild >> spec files, >> >> >> I believe that this ARC case needs to at least document >> and (hopefully) set some level of commitment to the >> well defined tag list. >> >> At a minimum this: >> http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/specdesc >> >> needs to be included in the ARC materials. >> >> But, I'm sure better documentation than above >> should be provided. Say perhaps a man page or two? >> >> Doug. >> >> >> >> On 05/ 1/10 02:16 AM, Brian Cameron wrote: >>> Albert: >>> >>>>>> The spec file syntax is also conceptually an exported interface, >>>>>> and it >>>>>> needs a stability level. It would be nice if the spec file syntax >>>>>> were >>>>>> part of the materials (I'm guessing it's documented somewhere >>>>>> anyway). >>>> The basic syntax is the same as rpmbuild spec files, and pkgbuild >>>> includes >>>> a set of predefined macros and supports some additional tags >>>> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php >>> True, although pkgbuild does support some Solaris/OpenSolaris specific >>> extensions, and it might be good to highlight those a bit more. >>> >>> For example, one thing I notice is that the new "IPS_package_name" >>> and "Meta(info.classification)" keys cause syntax errors if you try >>> to use an older version of pkgbuild. It would be nice if pkgbuild >>> had better backwards compatibility support and provided some mechanism >>> to allow people who just want to build SVR5 packages a way to tell >>> pkgbuild to ignore keys that provide features that are not going to be >>> used anyway. >>> >>> Brian >>> > From john.fischer@oracle.com Fri May 14 08:24:14 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4EFOEd7010864 for ; Fri, 14 May 2010 08:24:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4EFOBnn008736; Fri, 14 May 2010 10:24:12 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2F0053D1GBQQ00@nwk-avmta-2.sfbay.sun.com>; Fri, 14 May 2010 08:24:12 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2F003D21G9EW40@nwk-avmta-2.sfbay.sun.com>; Fri, 14 May 2010 08:24:09 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4EFO8uJ017633; Fri, 14 May 2010 15:24:09 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4EDigFC017093; Fri, 14 May 2010 15:23:58 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt353.oracle.com with ESMTP id 242083171273850571; Fri, 14 May 2010 08:22:51 -0700 Received: from [10.7.250.1] (/10.7.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 May 2010 08:22:47 -0700 Date: Fri, 14 May 2010 08:22:44 -0700 From: John Fischer Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BEAA328.9030503@oracle.com> To: Doug Leavitt Cc: "Laszlo (Laca) Peter" , Brian Cameron , Albert Lee , Sebastien Roy , PSARC-ext Message-id: <4BED6AC4.1090508@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_4Co2XGONgTAQepOeWE28bQ)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BED6B10.0078:SCFMA4539814,ss=1,pt=DBB_65838,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <4BE45527.4080500@oracle.com> <4BEAA328.9030503@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 50981 This is a multi-part message in MIME format. --Boundary_(ID_4Co2XGONgTAQepOeWE28bQ) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT All, Laca has supplied the last need spec (see attached). I have placed it in the case directory as well. I believe this covers the last issue for the case. I will close the case out today COB unless I hear otherwise. Thanks, John On 05/12/10 05:46 AM, John Fischer wrote: > All, > > I am extending the timer to Friday, May 14th, to allow Laca to > complete his document > on the spec files. I'll keep extending the timer until the document > is done. He has > shown me the document that he is producing and it will resolve this > need spec. Therefore, > when it is completed and available in the archives I will close the > case as approved. > > Thanks, > > John > > On 05/ 7/10 11:00 AM, John Fischer wrote: >> Doug, >> >> Does the attached document satisfy this request >> for additional documentation? >> >> Laca, if not please provide what Doug is requesting. >> I will extend the timer for another few days to address >> the request. >> >> Thanks, >> >> John >> >> >> On 05/ 3/10 09:53 AM, Doug Leavitt wrote: >>> In addition to the missing definitions for the >>> Meta(*.*), SUNW*, and IPS* keys commonly deployed >>> in pkgbuils spec files today, I also noticed that neither >>> the proposal or the case materials make any reference to >>> >>> %include Solaris.inc >>> >>> or any of the include files Solaris.inc ifself includes and >>> that are generally expected as part of current pkgbuild >>> spec files, >>> >>> >>> I believe that this ARC case needs to at least document >>> and (hopefully) set some level of commitment to the >>> well defined tag list. >>> >>> At a minimum this: >>> http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/specdesc >>> >>> needs to be included in the ARC materials. >>> >>> But, I'm sure better documentation than above >>> should be provided. Say perhaps a man page or two? >>> >>> Doug. >>> >>> >>> >>> On 05/ 1/10 02:16 AM, Brian Cameron wrote: >>>> Albert: >>>> >>>>>>> The spec file syntax is also conceptually an exported interface, >>>>>>> and it >>>>>>> needs a stability level. It would be nice if the spec file >>>>>>> syntax were >>>>>>> part of the materials (I'm guessing it's documented somewhere >>>>>>> anyway). >>>>> The basic syntax is the same as rpmbuild spec files, and pkgbuild >>>>> includes >>>>> a set of predefined macros and supports some additional tags >>>>> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php >>>> True, although pkgbuild does support some Solaris/OpenSolaris specific >>>> extensions, and it might be good to highlight those a bit more. >>>> >>>> For example, one thing I notice is that the new "IPS_package_name" >>>> and "Meta(info.classification)" keys cause syntax errors if you try >>>> to use an older version of pkgbuild. It would be nice if pkgbuild >>>> had better backwards compatibility support and provided some mechanism >>>> to allow people who just want to build SVR5 packages a way to tell >>>> pkgbuild to ignore keys that provide features that are not going to be >>>> used anyway. >>>> >>>> Brian >>>> >> > --Boundary_(ID_4Co2XGONgTAQepOeWE28bQ) Content-type: text/plain; name=pkgbuild-spec.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=pkgbuild-spec.txt The description of pkgbuild's spec files 1 Introduction pkgbuild uses build "recipes" called spec files to define what sources are used for building a component, how to set up the source tree, build the binaries and how to package them. The spec files used by pkgbuild are similar to RPM's spec files, but there are some differences. Because the resulting package formats (SVr4 and/or IPS) have different characteristics from RPM packages, pkgbuild uses additional spec file elements not used by RPM and there are also many elements of RPM spec files that are ignored by pkgbuild. This document describes the pkgbuild's spec file format with an emphasis on the differences from RPM spec files. A good general introduction to RPM spec files can be found in Chapter 13 of Maximum RPM by Edward C. Bailey. The book's ISBN is 0672311054 and is available as a PDF at http://www.redhat.com/docs/books/max-rpm/max-rpm.pdf or as HTML at http://www.rpm.org/max-rpm-snapshot/ch-rpm-inside.html 2 Overview of the format Spec files are plain text files. Lines starting with a # are comments. The percent character has a special meaning therefore it has to be escaped by another percent character, example: ./configure --default-zoom-level="50%%" Tags define various attributes of the package, for example the name, the locations of sources, build-time and runtime dependencies. Lines that define tags start with the name of the tag followed by a colon followed by the value of the tag, for example: Name: pkgbuild Version: 1.3.102 The %package directive can be used to assign a name to a subset of files. A package usually corresponds to a separate SVr4 and/or IPS package. A number of shell script fragments (scriptlets) control the build process: %prep sets up the source tree from tarballs and/or patches and/or other source files. %build is used to create the binaries. %install places the binaries in a temporary package prototype area in the same layout at they will appear in the binary package. %check performs sanity testing. %clean is used to clean up the build directories after the build. Each scriptlet is executed separately, which means that the environment variables set in one scriptlet do not affect other scriptlets. The binaries in the prototype area are used to create one or more packages (SVr4 and/or IPS). The contents of these packages are defined in %files and optionally, in the case of IPS packages, %actions sections. Macros and wildcards (globs) can be used in the package definitions. pkgbuild allows building hierarchical spec file structures by using information from other spec files or including them. The %use directive assigns a label to another spec file. The label can be used to refer to tags, macros and scriptlets in other spec files. For example: %use glib2 = glib2.spec ... Version: %{glib2.version} The %include directive is similar to the #include C preprocessor directive. While spec files are best written as generic and platform-agnostic as possible, sometimes it's necessary to add conditional statements. These are similar to the #if / #ifdef C preprocessor directives. Spec files include a %changelog section that documents the changes made to the file, including the date, the name or email address of the person who made the change and the description of the change. 3 Macros 3.1 Macro definitions Macros are defined using the %define statement: %define project_name pkgbuild Macro names can include letters, numbers and underscores (_) and they are case-sensitive. The percent character is used for expanding macros or tags. Macro or tag names can be enclosed in curly brackets when they would otherwise become ambiguous because of the characters that follow the macro name, e.g: %define _prefix /usr %define _lib lib %define _libdir %_prefix/lib %_libdir --> /usr/lib %{_lib}dir --> libdir %_libfoo --> %_libfoo (undefined macro) %{_lib}foo --> libfoo %project_name or %{project_name} In case of a conflict, tags mask macros: Version: 1.0 %define version 2.0 %{version} expands to 1.0 3.2 Conditional macro expansion Undefined macros do not get expanded. In most cases this is not desirable so conditional macro expansions can be used to deal with undefined macros. The following table summarizes the expansion of conditional macros when the "foo" macro is defined and the value is "bar" or not defined: | Expansion when %foo is Macro | defined as bar | undefined ------------------+--------------------------+------------------------- %foo | bar | %foo %{?foo} | bar | %{?foo:fred} | fred | %{?!foo:fred} | | fred %{!?foo:fred} | | fred Macro expansions can be nested: %define fred %{?foo}%{!?foo:%{bar}} 3.3 Using the output of external commands The %(command) expression can be used to colled the output of an external command, just like $(command) or `command` in shell scripts: %define os_release %(uname -r) 3.4 Predefined macros A number of commonly used macros are predefined in the macros file under $(libdir)/pkgbuild-$(version). The most useful ones are summarized below: Macro name | Default value -------------------+------------------------------ %_pkgbuild | pkgbuild %_is_pkgbuild | 1 %_pkgbuild_version | %buildroot | /var/tmp/--build | (this is the location of the proto area) %__install | /usr/bin/ginstall %__make | /usr/bin/make %__patch | /usr/bin/gpatch %__perl | /usr/perl5/bin/perl %__python | /usr/bin/python %__strip | /usr/ccs/bin/strip %_topdir | %{__homedir}/packages %_buildshell | /bin/bash %_builddir | %{_topdir}/BUILD %_pkgdir | %{_topdir}/PKGS %_sourcedir | %{_topdir}/SOURCES %_specdir | %{_topdir}/SPECS %_srcpkgdir | %{_topdir}/SPKGS %_pkgmapdir | %{_topdir}/PKGMAPS %_tmppath | %{_var}/tmp/pkgbuild-%__logname %_prefix | /usr %_exec_prefix | %{_prefix} %_bindir | %{_exec_prefix}/bin %_sbindir | %{_exec_prefix}/sbin %_libexecdir | %{_exec_prefix}/libexec %_datadir | %{_prefix}/share %_sysconfdir | %{_prefix}/etc %_sharedstatedir | %{_prefix}/com %_localstatedir | %{_prefix}/var %_lib | lib %_libdir | %{_exec_prefix}/%{_lib} %_includedir | %{_prefix}/include %_oldincludedir | /usr/include %_infodir | %{_datadir}/info %_mandir | %{_datadir}/man %_docdir | %{_datadir}/doc %_pkg_docdir | %{_docdir}/%{name} The following macros can be used to control pkgbuild's behavior: %_unpackaged_files_terminate_build 1 When set to 1, this requires all files in the proto area to be included in a binary package. %_missing_doc_files_terminate_build 1 This means that all documentation files flagged with the %doc modified in the %files list must exist. %_invalid_patches_terminate_build 1 When set to 0, patches that cannot be applied to the sources are skipped and the build continues without them. The default is that all patches must apply. %_use_ips_autotag 1 When set to 1, automatically add actuators to some well known file types (e.g. GNOME .desktop files, desktop icons, gconf schemas) 4 Tags Spec files contains lots of information about the component they belong to. Some of this information is used during the build process others are directly or indirectly used for in the binary packages to describe the package. Since spec files were invented for building RPM packages, not all tags make sense when building SVr4 or IPS packages and similarly, there are aspects of SVr4 and IPS packages that cannot be described by RPM's tags. Most tags are not required and either have a default value or can be omitted from the corresponding package's pkginfo or manifest file. The required tags are Name and Version. Note that RPM also requires Release, License, Summary and Group to be defined. 4.1 pkgbuild-specific tags This section describes the tags specific to pkgbuild's spec files and explains their use. Tags used for Solaris SVr4 packaging are prefixed with SUNW: SUNW_BaseDir: corresponds to BASEDIR in the pkginfo(4) file, default: / SUNW_Pkg: the package abbreviation (PKG parameter) in the pkginfo(4), defaults to %{name} SUNW_ProdName: SUNW_PRODNAME in pkginfo(4), omitted from pkginfo if not defined. SUNW_ProdVers: SUNW_PRODVERS in pkginfo(4), omitted from pkginfo if not defined. SUNW_Category: CATEGORY in pkginfo(4), default: application SUNW_Hotline: HOTLINE in pkginfo(4), omitted from pkginfo if not defined. SUNW_MaxInst: MAXINST in pkginfo(4), omitted from pkginfo if not defined. SUNW_Rev: REV part of the SVr4 version string. Defaults to $(date +%Y.%m.%d.%H.%M.%S) The full SVr4 version string is %{version},REV=%{sunw_rev} SUNW_Copyright: Name of the copyright file to be included in the prototype(4) file. Omitted, if not defined. The copyright file with the given name is expected to be in %_sourcedir (the SOURCES directory in the build area). Copyright files are passed through pkgbuild's parser for expanding macros. This is useful for repeating information from the spec file in the copyright file, for example the download URL: ... the source code was downloaded from %{SOURCE.url} ... SUNW_PkgList: SUNW_PKGLIST parameter in pkginfo(4), omitted if missing. SUNW_Loc: SUNW_LOC parameter in pkginfo(4), omitted if missing. SUNW_PkgType: SUNW_PKGTYPE parameter in pkginfo(4), defaults to "usr" if SUNW_BaseDir is /usr, "root, if SUNW_BaseDir is /, omitted otherwise. SUNW_Desc: DESC parameter in pkginfo(4), defaults to %{summary} SUNW_Pkg_AllZones: SUNW_PKG_ALLZONES in pkginfo(4), omitted from pkginfo if missing. SUNW_Pkg_Hollow: SUNW_PKG_HOLLOW in pkginfo(4), omitted from pkginfo if missing. SUNW_Pkg_ThisZone: SUNW_PKG_THISZONE in pkginfo(4), omitted from pkginfo if missing. Tags used for building IPS packages are prefixed with "IPS_": IPS_Package_Name: Defines the name of the IPS package. Default: %name IPS_SourcePackage: Defines the name IPS source package. Default: %{name}/src IPS_Component_Version: Sets the component version portion of the IPS package version string, as described in pkg(5). For example 2.20 in the case of this package: gtk2@2.20.0,5.11-0.133: IPS_Build_Version: Sets the build version portion of the IPS version string. 5.11 in the above example. See pkg(5). IPS_Vendor_Version: Sets the vendor-specific branch version portion of the IPS version string, 0.133 in the above example. See pkg(5). Meta is a special tag introduced for adding arbitrary metadata to IPS packages (using the 'set' action). The syntax is: Meta(attribute_name): value Example: Meta(info.classification): org.opensolaris.category.2008:Applications/Games Other commonly used Meta tags are: Meta(info.upstream): [name email of open source project leader] Meta(info.maintainer): [name email of ips pkg porter/maintainer] Meta(info.repository_url): [open source code repository] Spec file tags translate to IPS package attributes as follows: Name pkg.name Summary description Summary pkg.summary Url info.upstream_url (defaults to http://pkgbuild.sf.net/) Group info.classification (freedesktop.org:: is prepended to the value of Group) Meta() SUNW_Copyright payload of the license action License the description of the license in the license action Requires depend action A "legacy" action is also added to the manifest. It uses the package data defined for SVr4 packaging, for example SUNW_Pkg and SUNW_Category. 4.2 Source and Patch tags The names (and locations) of source files and patches (source diffs) are added as tags. The Source tag defines the nth source file name or URL and similarly, Patch defines the Nth patch file name or URL. Special macros exist for unpacking sources and applying patches in the %prep section, see 7.1 for details. The %SOURCE and %PATCH macros can be used to refer to the full local path to a copy of the given source or patch. They can also be written as %{S:} and %{P:}. A Source or Patch tag without a number is equivalent with Source0 or Patch0 respectively. To refer to the source URL, use %{SOURCE.url}. 4.3 Other tags The following tags are also implemented by pkgbuild: Name: name of the component (upstream package) Version: version of the component License: identification of the license, e.g. GPLv2 Copyright: (Obsolete) same as License BuildRoot: location of the prototype directory Group: classification of the package according to the freedesktop.org classification scheme NoSource: list of Source numbers not to be included in the source package, e.g. NoSource: 1 2 NoPatch: list of Patch numbers not to be included in the source package Vendor: name of package vendor Summary: one-line description of the package BuildRequires: build-time dependency Requires: runtime dependency BuildConflicts: package with a build-time conflict BuildPrereq: same as BuildRequires These tags are accepted by the parser but currently ignored by pkgbuild: Release, Epoch, Distribution, Icon, URL, Packager, AutoReqProv, Serial, BuildArchitectures, BuildArch, ExcludeArch, ExclusiveArch, ExcludeOS, ExclusiveOS, Prefix, Obsoletes, Provides, Conflicts, Prereq 5 Preamble Spec files start with a list of tag definitions that describe the entire component. This is called the Preamble in RPM's terminology. The information conveyed by the tags in the Preamble is generally stored as metadata in the generated package. Although only Name and Version are required, the following tags are usually present in the preamble: Name: the name of the component, preferably the upstream name, if the module comes from an external community Summary: a one-line description of the component Version: this tag defines the version of the binary package(s) built from the module therefore it has to meet the requirements of the packaging systems: a sequence of numbers separated by dots, no leading zeros. While it's a good idea to keep the Version the same as the upstream version, sometimes changes need to be made in order to meet the above requirement. In these cases a common practice is to define a macro called tarball_version and use it throughout the spec file whenever the upstream version number is needed. Examples: Name: jpeg %define tarball_version 6b Version: 6.2 Name: foo %define tarball_version 2.06 Version: 2.0.6 License: identification of the main license(s) in the package, for example License: GPLv3 Vendor: the name of the organization that builds the package. This tag is often found in an include file that is shared across a build environment, such as the OpenSolaris Desktop consolidations's Solaris.inc file. BuildRoot: location of the proto area where the binaries are laid out for packaging. Example: BuildRoot: %{_tmppath}/%{name}-%{version}-build SUNW_Copyright: OpenSolaris-compliant packages require a license file that describes the license of the component. This file is usually called %{name}.copyright: SUNW_Copyright: %{name}.copyright SUNW_BaseDir: the BASEDIR of the SVr4 package, if it's not "/". SUNW_BaseDir: %{_prefix} SUNW_Pkg: the SVr4 package abbreviation, if different from Name IPS_package_name: the IPS package name, if different from Name URL: a pointer to a web site with more information about the component Name: gtk2 URL: http://www.gtk.org/ Source, Source1, Source2, ...: list of sources, with full upstream URLs. Use the %{version} macro in the URLs instead of repeating it. Patch, Patch1, Patch2, ...: list of source patches (diffs) that will be applied to the sources. The naming convention used by the Desktop Consolidation and Source Juicer is: %{name}--.diff is a 2-digit number that specifies the order in which patches should be applied and is a short description of what the patch does. Example: Patch5: gtk+-05-sun-pgdn-pgup-keybindings.diff The Desktop Consolidation uses -p1 unified diffs (See the -p option in patch(1) and -u in diff(1)) BuildRequires: This tag declares one or more build-time dependencies of the component. Multiple dependencies can by separated by commas, but it is generally more readable to use multiple BuildRequires declarations instead. It is syntactically correct to specify required versions of dependencies, but pkgbuild does not currently enforce the version constraints. Example: BuildRequires: SUNWgtk2 > 2.10.0, SUNWglib2 >= 2.5.0 this is equivalent with: BuildRequires: SUNWgtk2 > 2.10.0 BuildRequires: SUNWglib2 >= 2.5.0 and in pkgbuild's current implementation the version is ignored: BuildRequires: SUNWgtk2 BuildRequires: SUNWglib2 The dependency can be a SVr4 package name, an IPS package name or a file name (full path): BuildRequires: SUNWbash BuildRequires: shell/bash BuildRequires: /usr/bin/bash Requires: similar to BuildRequires, but defines the runtime dependencies of the package. pkgbuild attempts to translate dependency specifications to package names native to the format of the package being created. File name dependencies are also translated to package names based on which package contains the file. BuildConflicts: opposite of BuildRequires. Declares that the presence of the given package(s) or file(s) is incompatible with the build process of this component. Conflicts: declares a conflicting binary package. Not currently implemented. A multi-line package description can be added at the end of the preamble, preceeded by the %description directive: %description Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. The text of the description ends when it reaches a line that starts with a keyword (e.g. %package, %build, %define). It is a common mistake to add more tags after the %description. They will not be recognized as tags and will become part of the description text. The current version of pkgbuild does not use the description, but it is still a good practice to add it. 6 Packages A spec file can define one or more SVr4 and one or more IPS packages. While the files in these packages are the same, the package boundaries need not be. The %package directive defines a group of files for the purpose of packaging and assigns a name that may or may not match either the IPS package name or the SVr4 package name of the given group of files. The %packages tag is followed by a number of tag definitions that apply to the package. By default, all tags inherit the value assigned in the main package. Dependencies, however, are not inherited, the package must declare its own dependencies using Requires tags. The %package directive has 2 forms: %package -n In the this form, the default behavior is that a separate SVr4 package called is created and also a separate IPS package with the same name. %package In this form, by default a separate SVr4 package called %{name}- is created but for the purpose of IPS packaging, the files are merged in the main package. In both cases the SUNW_Pkg and IPS_Package_Name tags can be used to change the default behavior. Setting SUNW_Pkg or IPS_Package_Name to a package name previously assigned to another package or the main package causes the files to be merged into that package. Otherwise a new package by that name will be created. Example 1: Name: foo ... %package devel Result: - SVr4: foo and foo-devel - IPS: foo (devel files merged into foo) Example 2: Name: foo ... %package -n foo-devel Result: - SVr4: foo and foo-devel - IPS: foo and foo-devel Example 3: Name: foo ... %package -n bar IPS_Package_Name: foo Result: - SVr4: foo and bar - IPS: foo Example 4: Name: foo ... %package bar IPS_Package_Name: bar SUNW_Pkg: foo Result: - SVr4: foo (bar merged into foo) - IPS: foo and bar After the last tag, a %description specific to the package can be added. The %description directive should use the same arguments as the corresponding %package directive: %package devel Requires: %name %description devel Development files for %{name} 7 Scriptlets Scriptlets are shell script fragments that interact with the component's native build system, for example GNU make and GNU autotools or ant or Python setuptools. They are responsible for performing all the steps necessary to produce the binaries that make up the packages and lay them out in the proto area. Each scriptlet is executed as a separate shell script. The interpreter used by the shell scripts is defined by the _buildshell macro, the default is /bin/bash. When using bash, pkgbuild sets the following environment variables before the scriptlet itself: RPM_SOURCE_DIR=%{_sourcedir} RPM_BUILD_DIR=%{_builddir} RPM_OPT_FLAGS=%{optflags} RPM_ARCH= RPM_OS= RPM_OS_REL= RPM_DOC_DIR=/usr/share/doc/packages/%{name} RPM_PACKAGE_NAME=%{name} RPM_PACKAGE_VERSION=%version RPM_PACKAGE_RELEASE=%release RPM_BUILD_ROOT=%buildroot It also sets the "-x" (print commands as they are executed) and "-e" (exit when a command fails) flags. See "set" in the "SHELL BUILTIN COMMANDS" section of bash(1) for more details. In the case of other interpreters the scriptlets are expected to return and exit status of 0 for success and non-0 in case of an error. pkgbuild executes the scriptlets in the following order: 1 prep 2 build 3 install 4 check 5 clean None of the scriptlets are required parts of a spec file. When missing, the build simply advances to the next stage. The -b option can be used to stop the build after a certain stage: p = %prep c = %prep and %build (c for compile) i = %prep, %build, %install and %check b = all of the above and build binary package(s) and run %clean a = all of the above and build a source package as well To execute only 1 stage, use the --short-circuit option, e.g. pkgbuild --short-circuit -bi foo.spec 7.1 %prep This section is responsible for preparing the source code. This includes unpacking tarballs, applying source patches, making other changes to the source files. In most cases unpacking the sources and applying patches is all that is needed, so pkgbuild (like rpmbuild) has high level macros for performing these steps: %setup Without any arguments %setup simply unpacks Source0, using whatever compression and unpacking methods necessary, based on the file name suffix. %setup has several flags that change its behavior (among others, they allow unpacking multiple tarballs). These are documented in detail in max-rpm: http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html The most commonly used options are: -q = quiet unpacking -n foo = declares that unpacking the source bundle creates a directory called foo. Use this macro, if foo is different from the default %name-%version -c = create a directory before unpacking the source bundle. Useful when the bundle does not create a top-level directory. The default is %name-%version. Use the -n option to change it. %patch The %patch macro is used to apply the Nth source patch to the source tree (using the GNU patch command). Use the -p option is passed to gpatch to remove levels of directories from the beginning of each file path. See gpatch(1). Other options are described in http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html Example: %prep %setup -q -n glib-%{version} %patch1 -p1 %patch2 -p1 %patch3 -p1 7.2 %build The build section creates the binaries. What exactly it does depends on the native build system of the component. In the case of a component that uses GNU autotools, it typically sets some environment variables (for example compiler flags), runs configure with some options (like --prefix and options the select/unselect features) and the runs make: %build export CFLAGS="%optflags" export PYTHON=/usr/bin/python2.6 ./configure --prefix=%{_prefix} \ --mandir=%{_mandir} \ --datadir=%{_datadir} \ --disable-fam make 7.3 %install The install scriptlet copies the files that will become part of the binary package(s) to a prototype area. The location of this directory is identified by the %{buildroot} macro and the $RPM_BUILD_ROOT environment variable (in the case of bash scripts). Components that use GNU autotools for their native build system typically use "make install DESTDIR=$RPM_BUILD_ROOT". Since pkgbuild requires that all files under $RPM_BUILD_ROOT are included in a package, files that the package developer does not want to include in packages (for example libtool's .la or Python's .pyo files) must be deleted. It is a good idea to clear $RPM_BUILD_ROOT at the beginning of the %install section to make sure that no files are left behind from a previous (possibly failed) build. Example: %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT # delete libtool .la files rm $RPM_BUILD_ROOT%{_libdir}/lib*.la 7.4 %check This section is executed immediately after %install and the purpose is to verify the integrity of the build by performing tests on the newly built binaries. Many components provide a "make check" target for this purpose. You can also use this section to verify that all required parts of the package were built (missing dependencies can cause features to be disabled at build-time): %check # sanity check: verify that some tricky modules were successfully built: for f in _ctypes.so _curses.so _curses_panel.so _elementtree.so \ _multiprocessing.so _sqlite3.so _ssl.so _tkinter.so crypt.so \ pyexpat.so sunaudiodev.so zlib.so dlpi.so ucred.so bz2.so; do test -f $RPM_BUILD_ROOT%{_libdir}/python%{majmin}/lib-dynload/$f || { echo ERROR: required module $f missing exit 1 } done 7.5 %clean This section (if present in the spec file) is run after the binary packages are created and it is used to clean up after the build. The most common command in this section is rm -rf $RPM_BUILD_ROOT which deletes the prototype area. 8 Installation scripts SVr4 package developers can "enhance" the functionality of their packages using installation scripts. Installation scripts are generally used to change the state of the system during installation or uninstallation. Given the number of different installation scenarios, it is difficult to get these scripts right and therefore the use of such scripts is discouraged. Although SVr4 packaging allows other kinds of packages as well, pkgbuild only implements scripts that are acceptable for integration into the Solaris OS. These scripts are described below in more detail. 8.1 Procedure scripts (pre-/post-install/uninstall) Below is the list of procedure scripts and the corresponding spec file sections: - preinstall = %pre - postinstall = %post - preremove = %preun - postremove = %postun Be default, the scripts are added to the main package. To add a procedure script to another package, use the same arguments as the corresponding %package directive: %package -n foo-devel ... %post -n foo-devel Short scripts can be inlined in the spec file: %pre echo Hello world The inline script can use spec file macros. They end at a line that starts with a spec file keyword (e.g. %post, %files, %changelog). Longer scripts are best kept in separate files and referenced using the -f option: %post devel -f %{name}-devel.postinstall 8.2 Class Action Scripts Class Action Scripts (CAS) are responsible to performing installation or removal actions on a set of files, typically by editing an existing (editable) file that is shared by multiple packages. Files that belong to a specific class must be flagged in the %files list using the %class(class_name) modifier (see Section 9.1 for more detail). To define a new class, you need to provide either an installation script (%iclass directive) or a removal script (%rclass directive) or both. Just like in the case of procedure scripts, CASs can also be inlined or referenced using the -f file_name option: %iclass myclass -f i.myclass System default CASs (those located in /usr/sadm/install/scripts) do not need to be defined in the spec file, they can be used in the %files lists with the %class modifier. 8.3 Installation scripts in IPS (or the lack of) The Image Packaging System does not allow any kind of scripting. The reasons are detailed here: http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting In the real world, however, some configuration is often necessary. The recommended solution is using transient SMF services to perform the configuration steps. Transient services are executed at system boot and IPS can also restart the services at the end of installation when any affected actions are tagged with "restart_fmri=svc://some/service". 9 Files and actions The contents of the package prototype area created in the %install section need to be sorted into binary packages. Most item are directories, files or symlinks. In the case of SVr4 packages, some of them may have special attributes like being volatile or having a class action script associated with them. In the case of IPS, there are all kinds of other actions as well, for example adding a new group or user. IPS actions that are not files, directories or symlinks can be defined in the %actions section. %actions sections are ignored when building SVr4 packages. 9.1 %files The %files section lists that files included in the main package and in the packages defined using %package directives. As explained in Section 6, these groups of files make up the SVr4 package and the IPS packages, but they do not necessarily include the same groups of files and the number of SVr4 packages created in the spec file may be different from the number of IPS packages. Without arguments, %files belongs to the main package. %files lists for other packages must use the same arguments as the corresponding %package directive: %package devel ... %files devel The %files list usually starts with the definition of the default file attributes: %defattr (file_mode, user, group[, dirmode]) file_mode is the default mode (permissions) of files in the package, specified as an octal number. user and group are the default owners of the files and directories. dirmode is the default mode of the directories. If omitted, it matches file_mode. Either of these parameters can be replaced with a dash, which means pkgbuild should use the attribute of the file/directory, as found in the prototype area. Since pkgbuild requires building as a non-privileged user, it is not a good idea to leave the user and group unspecified because pkgbuild will then use the build user's user name and group name in the package. A typical %files list start with: %defattr(-, root, root) A files list can contain multiple %defattr definitions, in which case they apply to the files listed after them. Automatically added parent directories use the attributes of the last %defattr statement in the %files list. All other lines in %files consist of a path name or path name pattern (shell-style glob) optionally prefixed by some modifiers. If path name is a directory, all contents of the directory are added recursively (unless the %doc modifier is used, see below). For portability, path names are usually written using macros: %{_bindir}/foo Patterns should be used with care: using too restrictive patterns require more work to maintain (more lines need to be updated when upgrading the component to a newer version), while too inclusive patterns may hide build errors that cause some files not to be present. Examples: Too restrictive: %{_datadir}/foo-doc/file1.html %{_datadir}/foo-doc/file1_a.html %{_datadir}/foo-doc/file1_b.html %{_datadir}/foo-doc/file2.html %{_datadir}/foo-doc/images/foo1.png ... Too inclusive: %{_libdir}/foo-plugins/* The following modifiers are implemented in pkgbuild: %attr - same as %defattr, but applies to the given line only %dir - when applied to a directory name, specifies that only the directory itself should be added, not the contents recursively. Useful when the permissions of the directory are different from its contents: %attr(0755, root, other) %{_datadir}/applications %{_datadir}/applications/foo.desktop %config - SVr4: when used in conjunction with %class(foo), it marks the file editable (type 'e') - IPS: it tags the file with preserve=\"renamenew\" %ghost - SVr4: marks the file volatile (type 'v') %class(class_name) - SVr4: declares that that file is part of class class_name. %ips_tag(foo=bar) - IPS: adds "foo=bar" as a tag on the given file example: %ips_tag(restart_fmri="svc:/foo/bar") %{_libdir}/fred %hard - when applied to a symlink, it becomes a hard link in the prototype / manifest. %doc - flags documentation files, see Section 9.1.2 %verify - ignored %docdir - ignored 9.1.1 Dynamically generated %files lists Sometimes sorting files into packages is inconvenient to do manually, for example if you need to separate a large number of files based on some pattern. pkgbuild (like rpmbuild) allows package developers to create a list of files during the build and use that in %files. Use the -f file_name flag to associate file_name with the %files list. pkgbuild will look for file_name in the top level build directory of the component (e.g. ~/packages/BUILD/foo-1.0/). The %files file (metafile) can list some or all files in the package: %files devel -f api_docs.lst %defattr (-, root, bin) %{_includedir}/foo.h The metafile is usually generated in the %install section: %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT find $RPM_BUILD_ROOT%{_datadir}/foo -name 'foo_API_*.html' -print \ | sed -e 's,$RPM_BUILD_ROOT,,' > api_docs.lst 9.1.2 %doc files pkgbuild (like rpmbuild) can help create "package documentation files". These files are part of the source tree and they are saved in a package-specific directory in the binary package for users to review. It can include README files, instructions, licensing information, examples, etc. Package documentation files are prefixed with the %doc modifier and are specified with a relative path. A whitespace-separated list of files can be specified in a single line. pkgbuild will look for the relative path under the top level source directory of the component. pkgbuild's implementation of the %doc modifier is slightly differs from rpmbuild's: - pkgbuild supports %doc(compress|gzip|bzip2) tag, this causes the files to be compressed with the chosen compression utility - the %{_pkg_docdir} macro can be used to refer to or to change the doc directory of a package - files in subdirectories of the top level source directory can be tagged with %doc: %doc po/ChangeLog The file will be placed in a subdirectory of the same name under %{_pkg_docdir} - %doc -d changes the directory to before looking for a documentation file. As a result, "subdir" will not be created in %{_pkg_docdir}. This is useful for example in the this source directory structure: ~/packages/BUILD/foo-1.0/ i386/foo-1.0/README, etc... amd64/foo-1.0/README, etc... in the package, we want the README file to be under /usr/share/doc/foo/README, and not under /usr/share/doc/foo/i386/foo-1.0/README, So in %files, use this: %doc -d %{base_arch}/foo-%{version} README 9.2 %actions The actions section is used to add arbitrary actions to the IPS manifest. Macros are expanded the in items of the %actions sections but no other processing or verification is performed. Like %files, %actions must also be linked to the corresponding %package: %actions group groupname="testpkg" user username="testuser" group="testpkg" %actions -n foo-driver driver name=foo perms="dump 0660 root sys" 9.3 autotag As mentioned in section 8.3, some files need additional processing after installation/update. This is usually done in SMF services and the restart_fmri IPS tag can be used to tell IPS to restart the services. "autotag" is a feature that automatically adds restart_fmri tags for some known types of files, for example SMF manifests, .desktop files, GConf schemas. Autotag also adds dependencies on the packages that include the SMF services to be restarted. Package developers can add their own tags using the IPS_tag modifier. To disable autotag, the spec file can set _use_ips_autotag to 0: %define _use_ips_autotag 0 or the user can set it on the pkgbuild or pkgtool command line: pkgbuild --define '_use_ips_autotag 0' -ba foo.spec and finally, it can also be disabled in ~/.pkgbuildmacros: %_use_ips_autotag 0 The current version of pkgbuild includes the following autotag rules: Path name regexp SMF service to restart Additional dependencies /etc/gconf/schemas/.*\.(schemas|entries)$/ svc:/applications/desktop-cache/gconf-cache:default SUNWdesktop-cache usr/share/icons/.* svc:/applications/desktop-cache/icon-cache:default SUNWdesktop-cache usr/lib/.*gtk-2.0/.*/immodule/.*\.so svc:/application/desktop-cache/input-method-cache:default SUNWdesktop-cache usr/share/mime/packages/.* svc:/application/desktop-cache/mime-types-cache:default SUNWdesktop-cache usr/lib/.*gtk-2.0/.*loaders/.*\.so svc:/application/desktop-cache/pixbuf-loaders-installer:default SUNWdesktop-cache usr/share/applications/.* svc:/application/desktop-cache/desktop-mime-cache:default SUNWdesktop-cache usr/X11/lib/X11/fonts/.*\.(ttf|pcf|pcf\.gz) svc:/application/font/fc-cache:default SUNWfontconfig var/svc/manifest/.*\.xml svc:/system/manifest-import:default 10 Multi-level spec file structures This section discusses some features intended to make it easier to create a consistent set of packages from a spec file repository. These features are incompatible with rpmbuild. 10.1 %include The %include directive works just like #include in the C preprocessor: it reads the contents of the include file as if it was included in the parent file where the %include line occurs. %include exists in rpmbuild as well, but the usage is slightly different. In rpmbuild, files to be included must listed with an absolute path and they do not get included in the source package unless they are also declared using a Source tag: Source5: foo.inc ... %include %SOURCE5 This above example works with both pkgbuild and rpmbuild. The include file (since it's a source) is expected to be in %_sourcedir, just like the rest of the sources. In pkgbuild's implementation, a relative path after %include is considered a part of the spec file therefore it is expected to be in %_specdir and is automatically included in the source package: %include Solaris.inc 10.2 %use The %use directive is more sophisticated. It allows referencing parts of another spec file through macro expansion. First, we need to assign a name or label to a spec file: %use glib2 = glib2.spec After this line, the parent spec file can refer to tags, macros and scriptlets of glib2.spec, for example: Version: %{glib2.version} and even: %setup %glib2.prep Macros in the referenced spec file (glib2.spec in the above example) are evaluated where the %use directive appears. For example, if glib2.spec define CFLAGS like this: CFLAGS="%{?optflags}" then defining (or redefining) %optflags before the %use statement affects what the above line is expanded into: %define optflags -xO2 %use glib2 = glib2.spec ---> CFLAGS="-xO2" Leveraging this behavior, it's easy to build the same component multiple times, with different parameters, and include them in the same package, for example 32-bit and 64-bit variants: %define optflags -fast -m64 %define _libdir %{_prefix}/lib/64 %use glib2_64 = glib2.spec %define optflags -fast %define _libdir %{_prefix}/lib %use glib2 = glib2.spec We now have 2 labels assigned to the same spec file. One has its macros expanded for a 64-bit build, the other for a 32-bit build. We can now write a %prep section that calls the %prep sections of each spec file, running them in separate subdirectories to avoid conflicts: %prep rm -rf %name-%version mkdir -p %name-%version/32 %glib2.prep -d %name-%version/32 mkdir -p %name-%version/64 %glib2_64.prep -d %name-%version/64 As we can see in the above example, when calling scriptlets of a %use'd spec file, the -d dir argument causes the scriptlet to be executed in dir. The working directory of the calling scriptlet does not change as a result of using the -d dir argument. Similarly, the %build and %install scriptlets can also call glib2's and glib2_64's corresponding scriptlets, using the -d dir argument: %build %{glib2.build} %name-%version/32 %{glib2_64.build} %name-%version/64 Rarely used, but it is also possible to reference tags in subpackages (defined with %package) in the child spec. For example, if glib2.spec has a devel subpackage: %package devel Summary: glib2 development files We can reference the Summary tag in glib2.spec's devel subpackage using %{glib2.devel.summary}. The %use directive is also useful when building the same spec file on Linux and Solaris/OpenSolaris is a goal. The Linux spec file can be left as it is and a Solaris spec file written that wraps the Linux spec file through a %use directive and macro expansions, adding the necessary Solaris-specific information like tags and packaging. 11 Conditionals While, ideally, spec files should be written as generic and architecture-agnostic as possible, sometimes different commands, options or settings are needed on different platforms. To process spec file lines on specific architectures only use the %ifarch conditional: %ifarch amd64 %define _libdir %{_prefix}/lib/amd64 %endif %ifarch sparcv9 %define _libdir %{_prefix}/lib/sparcv9 %endif It is also possible to list multiple acceptable architectures: %ifarch amd64 sparcv9 ... %endif The architectures that pkgbuild well accept as matches are those printed by the isainfo command. The %ifnarch conditional is the logical complement to %ifarch, it matches whose architectures that are not printed by isainfo: %ifnarch amd64 %endif The %ifos / %ifnos conditionals can be used to separate Solaris-specific parts of a spec file that may be built on other OSs as well: %ifos SunOS %endif The logical complement is %ifnos: %ifnos Linux ... %endif A generic %if statement is also available. In the current version of pkgbuild, it only accepts 1 for logical true 0 for logical false as its argument. Expression evaluation can be done in a subshell macro: %if %(test %foo = "fred" && echo 1 || echo 0) ... %endif The %else conditional can be used with any of the conditionals described above. 12 Changelog Spec files usually end with a %changelog section. While it's not required in pkgbuild, it is recommended to document all non-trivial changes in the spec file's %changelog section. The format of the %changelog is as follows: %changelog * - - - * - - where is in date(1) +"%a %b %e %Y" format, is a person's email address and/or name and is a short description of the change. Example: %changelog * Tue Jan 26 2010 - fred@example.com - bump version to 2.24.0 * Tue Mar 31 2009 - joe@example.com - initial version rpmbuild also requires that changelog entries are in descending chronological order. 13 Further reading SVr4 packaging: Solaris Application Packaging Developer's Guide: http://docs.sun.com/app/docs/doc/806-7008 IPS packaging: http://hub.opensolaris.org/bin/view/Project+pkg/documents RPM documentation: http://www.rpm.org/max-rpm-snapshot/ http://docs.fedoraproject.org/drafts/rpm-guide-en/ rpmbuild tutorial: Part 1: http://www-106.ibm.com/developerworks/library/l-rpm1/ Part 2: http://www-106.ibm.com/developerworks/library/l-rpm2/ Part 3: http://www-128.ibm.com/developerworks/linux/library/l-rpm3.html?dwzone=linux pkgbuild mailing list: http://lists.sourceforge.net/mailman/listinfo/pkgbuild-sfe-devel OpenSolaris software porters: http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/ http://mail.opensolaris.org/mailman/listinfo/sw-porters-discuss IRC: irc://freenode:net/#pkgbuild --Boundary_(ID_4Co2XGONgTAQepOeWE28bQ)-- From shawn.walker@oracle.com Fri May 14 15:04:54 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4EM4r1t016681 for ; Fri, 14 May 2010 15:04:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4EM4qSN033122; Fri, 14 May 2010 16:04:52 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2F00201K049V00@brm-avmta-1.central.sun.com>; Fri, 14 May 2010 16:04:52 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2F00FQ6K03Q860@brm-avmta-1.central.sun.com>; Fri, 14 May 2010 16:04:51 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4EM4p7n015203; Fri, 14 May 2010 22:04:51 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4EHwIKH022131; Fri, 14 May 2010 22:04:50 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 243189271273874674; Fri, 14 May 2010 15:04:34 -0700 Received: from [10.7.250.54] (/10.7.250.54) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 May 2010 15:04:34 -0700 Date: Fri, 14 May 2010 17:04:32 -0500 From: Shawn Walker Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BED6AC4.1090508@oracle.com> To: John Fischer Cc: Doug Leavitt , PSARC-ext , "Laszlo (Laca) Peter" , david.comay@oracle.com Message-id: <4BEDC8F0.9030403@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BEDC902.013B:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <4BE45527.4080500@oracle.com> <4BEAA328.9030503@oracle.com> <4BED6AC4.1090508@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 580 On 05/14/10 10:22 AM, John Fischer wrote: > All, > > Laca has supplied the last need spec (see attached). I have placed it > in the case directory as well. I believe this covers the last issue for the > case. I will close the case out today COB unless I hear otherwise. In response to section 3.0 of the proposal (I don't have the original email to respond to, apologies): The proposed IPS package name is "command/build/pkgbuild". That should probably be "package/pkgbuild". We don't currently have a "command/build" or "command" namespace for packages. Cheers, -Shawn From laszlo.peter@oracle.com Sat May 15 02:06:39 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4F96cpF018253 for ; Sat, 15 May 2010 02:06:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4F96clK026451 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 15 May 2010 03:06:38 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2G00111EN22V00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 15 May 2010 02:06:38 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2G00J0KEN19P20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 15 May 2010 02:06:38 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4F96bRr008306 for ; Sat, 15 May 2010 09:06:37 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4F3N1w4010242 for ; Sat, 15 May 2010 09:06:37 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 243805251273914358; Sat, 15 May 2010 02:05:58 -0700 Received: from [192.168.1.100] (/60.234.234.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 May 2010 02:05:58 -0700 Date: Sat, 15 May 2010 21:05:54 +1200 From: "Laszlo (Laca) Peter" Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BEDC8F0.9030403@oracle.com> To: Shawn Walker Cc: John Fischer , Doug Leavitt , PSARC-ext , david.comay@oracle.com Message-id: <1273914354.263.64.camel@tecra> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BEE641D.0074:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <4BE45527.4080500@oracle.com> <4BEAA328.9030503@oracle.com> <4BED6AC4.1090508@oracle.com> <4BEDC8F0.9030403@oracle.com> Status: RO Content-Length: 700 On Fri, 2010-05-14 at 17:04 -0500, Shawn Walker wrote: > On 05/14/10 10:22 AM, John Fischer wrote: > > All, > > > > Laca has supplied the last need spec (see attached). I have placed it > > in the case directory as well. I believe this covers the last issue for the > > case. I will close the case out today COB unless I hear otherwise. > > In response to section 3.0 of the proposal (I don't have the original > email to respond to, apologies): > > The proposed IPS package name is "command/build/pkgbuild". > > That should probably be "package/pkgbuild". We don't currently have a > "command/build" or "command" namespace for packages. Okay, "package/pkgbuild" it is then. Thanks Laca From doug.leavitt@oracle.com Sat May 15 09:23:08 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4FGN8i2022370 for ; Sat, 15 May 2010 09:23:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4FGN6lr028277; Sat, 15 May 2010 09:23:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2G00H03YUH4900@brm-avmta-1.central.sun.com>; Sat, 15 May 2010 10:23:05 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2G002HXYUHTN80@brm-avmta-1.central.sun.com>; Sat, 15 May 2010 10:23:05 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4FGN5uU028614; Sat, 15 May 2010 16:23:05 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4FGF8VO000899; Sat, 15 May 2010 16:23:02 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 267838611273940534; Sat, 15 May 2010 09:22:14 -0700 Received: from [10.7.251.243] (/10.7.251.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 May 2010 09:22:14 -0700 Date: Sat, 15 May 2010 11:22:12 -0500 From: Doug Leavitt Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BE45527.4080500@oracle.com> To: John Fischer Cc: "Laszlo (Laca) Peter" , Brian Cameron , Albert Lee , Sebastien Roy , PSARC-ext Message-id: <4BEECA34.6020709@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BEECA67.002B:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <4BE45527.4080500@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre6 Thunderbird/3.0.3 Status: RO Content-Length: 2613 I reviewed the pkgbuild-spec.txt documentation and I felt that that document exceeded my expectations and was exactly the type of information I was looking for. I also appreciate the additional documentation provided in specdesc.pdf. I am satisfied that my requests have been met. Thanks Laca. Doug. On 05/ 7/10 01:00 PM, John Fischer wrote: > Doug, > > Does the attached document satisfy this request > for additional documentation? > > Laca, if not please provide what Doug is requesting. > I will extend the timer for another few days to address > the request. > > Thanks, > > John > > > On 05/ 3/10 09:53 AM, Doug Leavitt wrote: >> In addition to the missing definitions for the >> Meta(*.*), SUNW*, and IPS* keys commonly deployed >> in pkgbuils spec files today, I also noticed that neither >> the proposal or the case materials make any reference to >> >> %include Solaris.inc >> >> or any of the include files Solaris.inc ifself includes and >> that are generally expected as part of current pkgbuild >> spec files, >> >> >> I believe that this ARC case needs to at least document >> and (hopefully) set some level of commitment to the >> well defined tag list. >> >> At a minimum this: >> http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/specdesc >> >> needs to be included in the ARC materials. >> >> But, I'm sure better documentation than above >> should be provided. Say perhaps a man page or two? >> >> Doug. >> >> >> >> On 05/ 1/10 02:16 AM, Brian Cameron wrote: >>> Albert: >>> >>>>>> The spec file syntax is also conceptually an exported interface, >>>>>> and it >>>>>> needs a stability level. It would be nice if the spec file syntax >>>>>> were >>>>>> part of the materials (I'm guessing it's documented somewhere >>>>>> anyway). >>>> The basic syntax is the same as rpmbuild spec files, and pkgbuild >>>> includes >>>> a set of predefined macros and supports some additional tags >>>> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php >>> True, although pkgbuild does support some Solaris/OpenSolaris specific >>> extensions, and it might be good to highlight those a bit more. >>> >>> For example, one thing I notice is that the new "IPS_package_name" >>> and "Meta(info.classification)" keys cause syntax errors if you try >>> to use an older version of pkgbuild. It would be nice if pkgbuild >>> had better backwards compatibility support and provided some mechanism >>> to allow people who just want to build SVR5 packages a way to tell >>> pkgbuild to ignore keys that provide features that are not going to be >>> used anyway. >>> >>> Brian >>> > From john.fischer@oracle.com Mon May 17 09:23:07 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4HGN7fO004096 for ; Mon, 17 May 2010 09:23:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4HGN5rx028109; Mon, 17 May 2010 11:23:05 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2K00B0NO6H3P00@nwk-avmta-2.sfbay.sun.com>; Mon, 17 May 2010 09:23:05 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2K006I3O6GAS80@nwk-avmta-2.sfbay.sun.com>; Mon, 17 May 2010 09:23:04 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4HGN4Sq016832; Mon, 17 May 2010 16:23:04 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HFvFih011089; Mon, 17 May 2010 16:22:58 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt353.oracle.com with ESMTP id 247346351274113326; Mon, 17 May 2010 09:22:06 -0700 Received: from [192.168.0.111] (/76.20.56.122) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 09:22:05 -0700 Date: Mon, 17 May 2010 09:22:00 -0700 From: John Fischer Subject: Re: PSARC/2010/138 - pkgbuild build engine In-reply-to: <4BEECA34.6020709@oracle.com> To: Doug Leavitt Cc: "Laszlo (Laca) Peter" , Brian Cameron , Albert Lee , Sebastien Roy , PSARC-ext Message-id: <4BF16D28.4010300@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BF16D63.0083:SCFMA4539814,ss=1,fgs=0 References: <4BCF1E20.7030507@oracle.com> <4BDB2F9B.5010405@oracle.com> <4BDB30BB.9080806@oracle.com> <4BDBD565.3080004@oracle.com> <4BDEFF73.5030404@oracle.com> <4BE45527.4080500@oracle.com> <4BEECA34.6020709@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 2871 All, With Doug's issues resolved. I am marking this case closed approved as this was clearly reviewed. Thanks, John On 05/15/10 09:22 AM, Doug Leavitt wrote: > I reviewed the pkgbuild-spec.txt documentation and I felt > that that document exceeded my expectations and was > exactly the type of information I was looking for. > > I also appreciate the additional documentation provided > in specdesc.pdf. > > I am satisfied that my requests have been met. > > Thanks Laca. > > Doug. > > > On 05/ 7/10 01:00 PM, John Fischer wrote: >> Doug, >> >> Does the attached document satisfy this request >> for additional documentation? >> >> Laca, if not please provide what Doug is requesting. >> I will extend the timer for another few days to address >> the request. >> >> Thanks, >> >> John >> >> >> On 05/ 3/10 09:53 AM, Doug Leavitt wrote: >>> In addition to the missing definitions for the >>> Meta(*.*), SUNW*, and IPS* keys commonly deployed >>> in pkgbuils spec files today, I also noticed that neither >>> the proposal or the case materials make any reference to >>> >>> %include Solaris.inc >>> >>> or any of the include files Solaris.inc ifself includes and >>> that are generally expected as part of current pkgbuild >>> spec files, >>> >>> >>> I believe that this ARC case needs to at least document >>> and (hopefully) set some level of commitment to the >>> well defined tag list. >>> >>> At a minimum this: >>> http://hub.opensolaris.org/bin/view/Community+Group+sw-porters/specdesc >>> >>> needs to be included in the ARC materials. >>> >>> But, I'm sure better documentation than above >>> should be provided. Say perhaps a man page or two? >>> >>> Doug. >>> >>> >>> >>> On 05/ 1/10 02:16 AM, Brian Cameron wrote: >>>> Albert: >>>> >>>>>>> The spec file syntax is also conceptually an exported interface, >>>>>>> and it >>>>>>> needs a stability level. It would be nice if the spec file >>>>>>> syntax were >>>>>>> part of the materials (I'm guessing it's documented somewhere >>>>>>> anyway). >>>>> The basic syntax is the same as rpmbuild spec files, and pkgbuild >>>>> includes >>>>> a set of predefined macros and supports some additional tags >>>>> (attributes/keywords): http://pkgbuild.sourceforge.net/man.php >>>> True, although pkgbuild does support some Solaris/OpenSolaris specific >>>> extensions, and it might be good to highlight those a bit more. >>>> >>>> For example, one thing I notice is that the new "IPS_package_name" >>>> and "Meta(info.classification)" keys cause syntax errors if you try >>>> to use an older version of pkgbuild. It would be nice if pkgbuild >>>> had better backwards compatibility support and provided some mechanism >>>> to allow people who just want to build SVR5 packages a way to tell >>>> pkgbuild to ignore keys that provide features that are not going to be >>>> used anyway. >>>> >>>> Brian >>>> >>