SourceForge.net Logo    pkgbuild

 
About
Manual
Screenshots
License
Download
Bugs
Mailing lists
SFE
Wiki
 

Manual

  • Introduction to building JDS using pkgbuild at OpenSolaris.org

  • pkgbuild is meant to be compatible with rpm in terms of the spec file format. If you need an introduction to RPM spec files, see this tutorial: part 1, part 2, part 3.

    More complete RPM documentation in the RPM Guide and max-rpm.

  • pkgbuild-specific stuff

    While compatibility with RPM is important, some Solaris SVr4 package elements and attributes don't have equivalents in RPM.

    • pkgbuild specific tags:

      SUNW_BaseDir prefix

      Define prefix as the value of the BASEDIR field in the SVr4 pkginfo file. All path names in the %files section of this package must be under prefix otherwise pkgbuild will abort with an error. BASEDIR defaults to "/".

      SUNW_Pkg name

      Set the Solaris SVr4 package abbreviation to name. (This is the name you use with the pkgadd command.) By default, the package abbreviation will be the value of the Name tag.

      SUNW_ProdName name

      SUNW_PRODNAME field in the Solaris pkginfo file.

      SUNW_ProdVers version

      SUNW_PRODVERS field in the Solaris pkginfo file.

      SUNW_Category category_name

      CATEGORY field in the Solaris pkginfo file.

      SUNW_HotLine text

      HOTLINE field in the pkginfo file of the Solaris package.

      SUNW_MaxInst num

      num is the value of the MAXINST field in the Solaris pkginfo file. It's the maximum number of instances of the pkg allowed to be installed on a system.

      SUNW_PkgList pkg

      SUNW_PKGLIST field in the Solaris pkginfo file (for l10n packages): the list of packages that this package provides localisation content for.

      SUNW_Loc locale1,locale2,...

      SUNW_LOC tag for the pkginfo file (l10n packages)

      SUNW_Rev rev

      set the REV part of the version string to REV=rev

      SUNW_Copyright file

      Define file as the name of the file that contains the copyright information for the package.

      SUNW_PkgType type

      Overrides the default (root or usr) PKGTYPE values.

    • Macros:

      %include file

      The %include macro is not specific to pkgbuild, however I didn't know that when I first implemented it and so it's slightly different, although backwards compatible with rpm's %include.

      If file is an absolute path name, it won't be included in the source package unless it's explicitely listed as a source. (so far the same as with rpm). If file is just a file name (or a relative path) pkgbuild will look for it in %_specdir (%_topdir/SPECS) and will include it in the source package. Examples:

      The rpm way of using %include:

      	 Source1: somefile.txt
      	 ...
      	 %include %SOURCE1
      	 
      In this example, %SOURCE1 will be expanded to an absolute path name (%_sourcedir/somefile.txt) so pkgbuild will find it in %_sourcedir and the source package will include somefile.txt in the SOURCES subdirectory but not in SPECS.

      pkgbuild specific use of %include:

      	 %include defaults.inc
      	 
      This will look for defaults.inc in %{_specdir}. defaults.inc will be included in the SPECS subdirectory of the source package.

      %use label = spec-file

      Declare that parts of %_topdir/SPECS/spec-file will be referenced later in this spec file using label. See %label.def and %label.scriptlet below for details.

      Note: any macros %defined before the %use line will also be in effect in spec-file (as if they were prepended to that file). For example:

      	 %define _prefix /opt/gtk
      
      	 %use gtk = gtk2.spec
      	 ...
      	 Version: %{gtk.version}
      
      	 ...
      
      	 %prep
      	 %gtk2.prep
      
      	 ...
      	 %build
      	 %gtk2.build	 
      	 
      In this example, the %prep and %build sections execute the %prep and %build section of gtk2.spec. However, unless gtk2.spec redefines %_prefix, it's value will be /opt/gtk.

      %label.def or %{label.def}

      Reference to a %define'd macro in the spec file label, as defined by a preceding %use. Gets replaced with the expansion of the referenced macro. E.g. %{gtk._datadir}

      %label.tag or %{label.tag}

      Reference to the value of a tag in the spec file label. E.g. %{gtk.version}

      %label.scriptlet [-d directory] or %{label.scriptlet} [-d directory]

      Execute scriptlet from the spec file label. If -d directory is used, cd into directory before executing the scriptlet and return to the original directory afterwards. Example:

      	 %use gtk12 = gtk-1.2.x.spec
      	 %use gtk28 = gtk-2.8.x.spec
      
      	 ...
      
      	 %prep
      	 %gtk12.prep
      	 %gtk28.prep
      	 

      %label.package.tag or %{label.package.tag}

      Reference to the value of a tag in a package (subpackage) in the spec file called label.
      Example: %{gtk.gtk-devel.summary}
      Note that is not full tested, let me know if you find bugs.

      %iclass class_name [-f file] or

      %iclass class_name
      inline script

      Use file or the inline script as the "i" (installation) script for class class_name. file should be in %_sourcedir.

      %rclass class_name [-f file] or

      %rclass class_name
      inline script

      Use file or the inline script as the "r" (uninstallation) script for class class_name. file should be in %_sourcedir

      %class (class_name) file

      To be used in a %files section to make file part of class class_name. Can be used in combination with %attr, %config, etc. %iclass or %rclass or both must to be defined for class class name unless class_name is a system class with an "i" and/or "r" script in /usr/sadm/install/scripts.

      %hard file

      A modifier to be used in a %files section to make all symlinks matching file be hard links ('l' in the pkgmap).

    Last Updated: laszlo.peter _at_ gmail.com 2008-03-16