Creating Packages

From RockWiki

Jump to: navigation, search

Creating a ROCK Linux package can be easy or difficult, depending on the program being packaged. In the most basic form a ROCK package consists of only the .desc file as in the example of the scmxx package: https://www.rocklinux.net/svn/rock-linux/trunk/package/blindcoder/scmxx/scmxx.desc Have a look at the Desc file syntax for information about how this file is structured.

If the program being packaged uses the GNU autotools then this is really all you need. If the package uses autotools can be identified easily: if the package can be installed using

./configure && make && make install

then the program uses autotools.

Contents

Helper Scripts

There are two scripts that help you in creating a new package:

  • misc/archive/fmnewpackage.sh
  • misc/archive/newpackage.sh

fmnewpackage.sh

The fmnewpackage.sh script can be used to create a new package based on its project details on https://freshmeat.net/.

For the scmxx package the command to run would then be:

# bash misc/archive/fmnewpackage.sh package/blindcoder/scmxx scmxx

Much of the information the .desc file must contain will then be extracted from the projects site and inserted in the packages .desc file (package/blindcoder/scmxx/scmxx.desc in this case)

newpackage.sh

The newpackage.sh script is less intelligent than the fmnewpackage.sh script, but still a great help. It creates the packages .desc file with a correct syntax and useful layout so you just have to substitute the TODOs with correct content.

For the scmxx package the command to run would then be:

# bash misc/archive/newpackage.sh package/blindcoder/scmxx https://dl.sourceforge.net/sourceforge/scmxx/scmxx-0.7.4.tar.bz2

Note that you can give as many files to download as you want.

More Information

If the program you want to package does not use the GNU autotools then you have to do some more work.

Programs that can't be built using the GNU autotools toolchain or that need parameters upon specific conditions or that have to change the behavior of other packages or ... well, there are literally hundreds of reasons why the simple rule of three might not be sufficient.

Other automations

The GNU autotools are well suited for a wide range of applications. But there are others that are widely used and by far more useful than that for their specific area. Three of them are automatically recognized by ROCK and need no further work on behalf of the package.

Makefile

The first one is a handwritten Makefile that builds and installs the program by means of the following two commands:

  1. make
  2. make install

Makefile.PL

The second one is the method used for most (all?) perl modules, Makefile.PL. Note that for perl modules that live in CPAN (https://www.cpan.org/) you should add them to the ImportCPAN package.

setup.py

The third one is setup.py ... Template:Stub

controlling the automations

The mentioned automations can be controlled using variables in the packages .conf file:

  • config

this variable holds the name of the current configuration. Configurations are stored in rock-src/config/

  • rockver

this variable holds the current ROCK Linux version

  • pkg

this variable holds the base name of the package currently built

  • xpkg

this variable holds the derived name part of the package currently built. If a package is not pkgforked then this is equal to pkg. Have a look at Package Forking for more information.

  • ver

this variable holds the version of the package. Derived from the V-Tag in the packages .desc file.

  • extraver

this variable holds the extraversion of the package taken from the V-Tag of the .desc file. This used to default to $rockver but that behaviour changed in SubMaster Patch 2004120809444327416

  • desc_[A-Z]

these variables hold the raw data of the tags in the packages .desc file. Have a look at the Desc file syntax for possible variables.

  • id

this variable holds the unique ID for this Build-Pkg invocation

  • arch

this variable holds the architecture this package should be built for. This is identical to the name of the directory in rock-src/architecture/

  • target

this variable holds the target this package is built for. This is identical to the name of the directory in rock-src/target/

  • stagelevel

this variable holds the stagelevel the build is currently in. Possible values are:

    • 0-1
      CrossBuild stage
    • 2-8
      NativeBuild stage
    • 9
      ReBuild stage
  • archdir

directory containing the package source files (rock-src/download/...)

  • confdir

directory containing the package build configuration (rock-src/package/...)

  • targetdir

directory containing the target configuration (rock-src/target/...)

  • builddir

directory in which the package is built (rock-src/src.$id)

  • base

ROCK base directory (rock-src/)

  • root

root directory (usually '/')

  • xroot

real root (/R.work/build/... when in chroot mode)

  • build_logs

directory where the build logfiles are (only during Build-Target)

  • build_pkgs

directory where the precompiled packages will be stored (only during Build-Target)

  • build_root

directory to be chroot'ed into (only during Build-Target)

  • build_rock

ROCK build system data (only during Build-Target)

  • prefix

installation prefix (usually '/usr' or '/opt/...')

  • prefix_auto

if this variables is set to '1' then the .conf file may overwrite the prefix variable

  • bindir

where the binaries (programs) should be installed (usually '$prefix/bin')

  • sbindir

where the system binaries should be installed (usually '$prefix/sbin')

  • libdir

where the library files should be installed (usually '$prefix/lib')

  • sysconfdir

where the configuration files should be installed (usually '$prefix/etc')

  • datadir

where the architecture independent data should be installed (usually '$prefix/share')

  • docdir

where the documentation should be installed (usually '$prefix/share')

  • mandir

where the man pages should be installed (usually '$datadir/man')

  • infodir

where the info files should be installed (usually '$datadir/info')

  • includedir

where the header files should be installed (usually '$prefix/include')

  • autoextract

if set to '0' then the source files will not be automatically extracted

  • autopatch

if set to '0' then the patch files will not be automatically applied

  • chownsrcdir

if set to '0' then the extracted sources will not be automatically chown'ed to root.root

  • nocvsinsrcdir

if set to '0' then directories named 'CVS' or '.svn' will not be automatically deleted

  • srctar

filename of the source tar file ('auto' means autodetection)

  • srcdir

directory in the tar file that holds the actual source files ('auto' means autodetection)

  • xsrctar

fliename of source tar file after 'auto' has been processed

  • xsrcdir

directory in source tar file after 'auto' has been processed

  • taropt

tar options for extracting the source tar

  • createprefix

if set to '0' then the directory skeleton for $prefix will not be created

  • createdocs

if set to '0' then the documentation files will not automatically be copied

  • autoso2a

if set to '1' then all *.so files will automatically converted to *.a files (the *.so files will not be deleted)

  • custmain

command to execute instead of the automatically detected method (see [#other automations] above)

  • mainfunction

alternate main function instead of build_this_package()

  • prepare

command to execute before main build block

  • prepatch

command to execute before automatic patching

  • patchfiles
    list of patchfiles to apply. This will be initialised with the following patterns:
    • $confdir/*.patch
    • $confdir/*.patch.$arch
    • $confdir/*.patch_$xpkg
    • $confdir/*.patch_$xpkg.$arch
    • $targetdir/pkg_$pkg.patch
    • $targetdir/pkg_$pkg.patch.$arch
    • $targetdir/xpkg_$xpkg.patch
    • $targetdir/xpkg_$xpkg.patch.$arch
  • postpatch

command to execute after automatic patching

  • patchopt

options to be passed to Template:Patch

  • preconf

command to run before running ./configure

  • runconf

set to '0' if you don't want to run ./configure

  • autogen

set to '1' if you want to run the autogen script

  • automakever

automake version (e.g. "-1.7") to use for $autogen

  • confopt

options to pass to ./configure

  • extraconfopt

options to be appended to $confopt

  • configprefix

variable declarations only for GNU autoconf './configure'

  • configscript

script file name of the GNU autoconf configure script

  • configexec

command for executing $configscript (default=bash)

  • pyconfopt

options for 'setup.py' - Python setup scripts

  • runxmkmf

set to '0' if you want to skip running 'xmkmf'

  • runmkpl

set to '0' if you want to skip running 'perl Makefile.PL'

  • runpysetup

set to '0' if you want to skip running 'python setup.py'

  • premake

command to execute before running 'make'

  • makeopt

options for 'make' (default = ' ')

  • inmake

command to execute between 'make' and 'make install'

  • makeinstopt

options for 'make install' (default = 'install')

  • postmake

command to execute after running 'make install'

  • postflist

command to execute after creating the flist

  • postinstall

command to execute after finishing all the standard stuff

  • finish

command to execute after everything else outside build-block

  • crossnative

has the value 'cross' or 'native'

  • archprefix

prefix for binutils and compiler binaries (for cross-building)

  • flistdel

regex describing files which shouldn't go to package db

  • flistrfilter

regex describing which lines to ignore in flist rlog

  • flistroot

list of top-level directories which should be used for flist

  • check_shared

Check for files which are shared with other packages

  • check_usrlocal

Check for files which are installed in usr/local

  • check_badfiles

Check for files which are registered 'bad files'

  • BUILDCC

C compiler for helper apps (usually that's just 'cc')

  • BUILD_CC

C compiler for helper apps (must be the same as $BUILDCC)

  • HOSTCC

C compiler for helper apps (must be the same as $BUILDCC)

  • HOST_CC

C compiler for helper apps (must be the same as $BUILDCC)

  • MAKE

make executable name (including -j option according to Config)

  • CC

C compiler executable name for target architecture

  • CXX

C++ compiler executable name for target architecture

  • STRIP

strip executable name for target architecture

  • LD

ld executable name for target architecture

  • AR

ar executable name for target architecture

  • RANLIB

ranlib executable name for target architecture

  • AS

as executable name for target architecture

  • GASP

gasp executable name for target architecture

  • NM

nm executable name for target architecture

  • CC_WRAPPER_*

configuration for C compiler wrapper

  • CXX_WRAPPER_*

configuration for C++ compiler wrapper

  • KCC_WRAPPER_*

configuration for Kernel C compiler wrapper

  • F77_WRAPPER_*

configuration for Fortran 77 compiler wrapper

  • STRIP_WRAPPER_*

configuration for strip wrapper

  • ROCK_BUILD_TARGET

set to '1' in Build-Target

  • ROCKCFG_*

configuration from 'Config' file

manual build

If you need to create a complex configuration for your package (the Linux kernel, for example) or the existing automations can't help you you need to configure and compile the package manually. Best Practice for creating your own build instructions is to use the custmain variable which is the substitute for the ./configure && make && make install stage. That means, that the sources will automatically be extracted and patched for example unless you tell ROCK not to do so using the variables from above.

Example:

foobar_main(){
        gcc -o foobar sources/*.c -lncurses
        install -m 0755 foobar $root/$prefix/bin
}

custmain="foobar_main"
Retrieved from "https://www.rocklinux.net/wiki/Creating_Packages"