Packages

The packages part contains all necessary information to att or split the compiled binaries, libraries and all other stuff into packages. Also runtime dependencies and needed actions after the (un)install or update process will be defined here.

Note!
Please respect all existing packaging rules!

A package with all defined instructions and scripts, can look like this example form openssh:

package openssh-server
    summary = OpenSSH server applications.
    description = %{summary}

    # /usr/bin/ssh-keygen is needed to generate keys for the ssh server.
    requires = /usr/bin/ssh-keygen

    files
/etc/pam.d/sshd
/etc/ssh/moduli
/etc/ssh/sshd_config
/lib/systemd/system/openssh.service
/usr/lib/openssh/sftp-server
/usr/lib/openssh/ssh-keygen
/usr/sbin/sshd
        /usr/share/man/cat5/sshd_config.5*
        /usr/share/man/cat5/moduli.5*
        /usr/share/man/cat8/sshd.8*
        /usr/share/man/cat8/sftp-server.8*
/var/lib/sshd
    end

    configfiles
/etc/ssh/sshd_config
    end

    prerequires = shadow-utils systemd-units

    script prein
# Create unprivileged user and group.
getent group sshd || groupadd -r sshd
getent passwd sshd || useradd -r -g sshd \
    -d /var/lib/sshd -s /sbin/nologin sshd
    end

    script postin
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
    end

    script preun
/bin/systemctl --no-reload disable openssh.service >/dev/null 2>&1 || :
/bin/systemctl stop openssh.service >/dev/null 2>&1 || :
    end

    script postun
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
    end

    script postup
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
    end
end

package

With package + name, you instruct the build system to create a package. The name has to be unique and it is recommended to use %{name} for the main package.

Note!
The buildsystem only creates packages if there is at least one specified. Don't worry about, a non existing or missing output if you forget to specify any packages!

template

To reduce the amount of needed instructions for well known types of packages, we created so calledTEMPLATES. These templates contains all needed package information, like:

  • summary
  • description
  • version
  • files

The following templates are available:

  • LIBS | For library packages
  • DEBUGINFO | A template for packages to ship the stripped debugging symbols
  • DEVEL | For devel packages
  • DOCS | To ship documentation files in an own package
  • MAIN | Main packages ( default if there aren't any other information )
  • PYTHON | A template for python 2 script files and compiled libraries.
  • PYTHON3 | A template for python 3 script files and compiled libraries.
Note!
It's not allowed to use a template multiple times in a NM file!

Example for using templates from udev package:

packages
    package %{name}
groups += Base
    end

    package lib%{name}
template LIBS
    end

    package lib%{name}-devel
template DEVEL
    end
end

summary

Same as in the header section of a NM file.

description

Same as in the header section of a NM file.

requires

Contains a list of dependencies that are required to use the package or launch the binaries or scripts.

Note!
You have to add your dependencies with a += because some tools already has been added by default and they would be overwritten if you only use a simple =.

On multiple requirements its recommended to create a "requires block" instead of a simple line, to keep the syntax as clear as possible.

requires
    dbus
    python-cairo
    python-dbus
    %{name}-units=%{thisver}
    udev>=172
    util-linux>=2.19
end

provides

To add additional contents or functions which a package offers.

Example from rsyslog:

provides += syslog

conflicts

If a package conflicts an other package for several reasons, you have to specify that here.

Example from shadow-utils:

pam<1.1.0-4

obsoletes

Use this, if a package obsoletes any other package. For example, the apache Web server package became the httpd package. You would expect the new package, httpd, to obsolete the old package name, apache.

recommends

Recommends are soft dependencies, they automatically will be installed, but it's possible to disable the installation of recommended packages by a command line option.

configfiles

If a package offers config files which never should be overwritten by an update, add them to this section.

datafiles

Datafiles are very similar to configfiles, and will be used for logfiles, database files or other files, which
should not be overwritten or removed by any kind of pakfire instruction.

files

Use this block to specify which files a package should contain.

prerequires

If there are any special tools or packages needed to run any scripts, you will have to specify them here.

Examples:
* shadow-utils to create a user or group
* systemd-units to deal with service files

scripts

Scripts runs commands at a defined moment. The following moments are available:

  • prein | To launch the commands before the package will be installed.
  • postin | To launch the commands after the package has been installed.

  • preup | To launch the commands before the package will be updated.

  • postup | To launch the commands after the package has been updated.

  • preun | To launch the commands before the package will be uninstalled/removed.

  • postun | To launch the commands after the package has been uninstalled/removed.

Example scripts from suricata package:

script postin
    /bin/systemctl daemon-reload >/dev/null 2>&1 || :
end

script preun
    /bin/systemctl --no-reload disable suricata.service >/dev/null 2>&1 || :
    /bin/systemctl stop suricata.service >/dev/null 2>&1 || :
end

script postun
    /bin/systemctl daemon-reload >/dev/null 2>&1 || :
end

script postup
    /bin/systemctl daemon-reload >/dev/null 2>&1 || :
    /bin/systemctl try-restart suricata.service >/dev/null 2>&1 || :
end
Edit Page ‐ Yes, you can edit!

Older Revisions • January 7 at 3:21 am • Jon