Packages other than RPM packages
This section discusses packaging documents for distribution through the RPM Package Manager. However, when you use the publican package
command, Publican generates a tarball that you can use to build a package to distribute through different package manager software. If you run publican package
on a computer on which rpmbuild is not installed, Publican still generates the tarball, even though it cannot then generate an RPM package from that tarball.
After you create a brand (as described in
Section 4.2, “Creating a brand”),
Publican can help you to distribute the brand to members of your documentation project as
RPM packages. RPM packages are used to distribute software to computers with Linux operating systems that use the
RPM Package Manager. These operating systems include Red Hat Enterprise Linux, Fedora, Mandriva Linux, SUSE Linux Enterprise, openSUSE, Turbolinux, and Yellow Dog Linux, to name just a few.
Publican can produce both source RPM packages (SRPM packages) and binary RPM packages.
An SRPM package contains the source code used to generate software rather than the software itself. To use an SRPM package, a computer must compile the source code into software. SRPM packages of Publican brands contain the configuration files, XML files, and image files that define the brand in its original language, plus the PO files that generate the Common Content files in translated languages. To install a brand from its SRPM package to a computer, the computer must have Publican installed on it. When you try to install the SRPM package on a computer that does not have Publican installed, the RPM Package Manager looks for Publican in the software repositories that are available to it. The RPM Package Manager installs Publican first, so that it can build and install the brand contained in the SRPM package. If the RPM Package Manager cannot find and install Publican, installation of the SRPM package will fail.
Conversely, binary RPM packages contain software — in this case, a Publican brand — that is ready to copy to a location in the computer's file system and use immediately. The contents of the binary RPM package do not need to be compiled by the computer onto which they are installed, and therefore, the computer does not need to have Publican installed.
To package a brand, use the publican package
command in the brand directory. When used without any further options, Publican produces an SRPM package. The options for packaging a brand are as follows:
--binary
specifies that Publican should build the package as a binary RPM package.
--brew
specifies that Publican should push the completed package to Brew. Brew is the build system used internally by Red Hat; this option is meaningless outside Red Hat.
--scratch
when used together with the --brew
option, specifies that a SRPM package should be built as a scratch build when sent to Brew. Scratch builds are used to verify that a SRPM package is structured correctly, without updating the package database to use the resulting package.
The
--lang
,
--desktop
and
--short_sighted
options that apply when you package books (described in
Section 3.5, “Packaging a book”) are meaningless when you package brands. In particular, note that although the
--lang
option is mandatory when you package a book, you do not need to use it when you package a brand.
By default,
Publican brand packages are named
publican-brand
-version
-release
.[build_target]
.[noarch].file_extension
.
Publican uses the information in the
publican.cfg
file to supply the various parameters in the file name. Refer to
Section 4.3.1, “The publican.cfg file” for details of configuring this file. Additionally:
SRPM packages have the file extension .src.rpm
but binary RPM packages have the file extension .rpm
binary RPM packages include [build_target]
.noarch
before the file extension, where [build_target]
represents the operating system and version that the package is built for as set by the os_ver
parameter in the publican.cfg
file. The noarch
element specifies that the package can be installed on any system, regardless of the system architecture.