The Linux Foundation is a non-profit consortium dedicated to fostering the growth of Linux.
|
|
Book/Packaging
From The Linux Foundation
Contents |
Packaging Your LSB Application
The LSB specifies application packaging in order to ensure compatibility between applications and the Linux distributions. Packaging can be distribution specific, so it is possible that your application will not run across distributions if you do not follow the LSB packaging specifications. In this chapter you will learn about the RPM file format for the correct locations for installing your applications.
Using RPM for Packaging
There are over one hundred Linux distributions to choose from for end-users to run their applications on. [1] To ensure applications will be able to install successfully, the LSB specifies the RPM file format as the best possible solution. It is the responsibility of the LSB Certified Runtime Environment (aka: operating system or Linux distribution) to be able to install RPM packaged applications. The book Maximum RPM, by Edward Bailey, and the RPM Web site are excellent resources for learning to create RPM packages. For the examples in this chapter, don't worry about the details, but just recognize that there are guidelines where to install most everything.
For reliability, an application cannot be dependent on itself for installation because ad hoc installers are not guaranteed to work. The RPM file format has been specified because it is widely acceptable by many Linux distributions; however, you may use another packaging format if the install program your application is dependent on is LSB certified and previously installed. [2]
Notes
|
[1] | |
|
[2] |
Portions of this chapter were derived with permission from Where to Install my Products on Linux?, George Kraft IV, November 2000, Linux Journal. |
Creating LSB Compliant RPMs
LSB-conforming RPM packages are restricted in certain ways. An important restriction is in package dependencies. The LSB specification makes these two statements:
- Packages shall have a dependency that indicates which LSB modules are required. LSB module descriptions are dash separated tuples containing the name 'lsb', the module name, and the architecture name.
- Packages shall not depend on other system-provided dependencies. They shall not depend on non-system-provided dependencies unless those dependencies are fulfilled by packages which are part of the same application. A package may only provide a virtual package name which is registered to that application.
Since LSB 3.1, the single dependency "lsb" serves as a meta-dependency, eliminating the need for individual module dependencies (these are legal, but deprecated - see the Desktop specification.
There are at least two ways to create an RPM package that conforms to LSB:
- using rpmbuild directly;
- using makelsbpkg tool included in the LSB SDK.
The latter is a wrapper for rpmbuild that tries to perform all routine work for you.
If you still want to invoke rpmbuild directly, then in order to meet the LSB requirements, you should not allow it to auto-generate dependencies. The spec file directives to get the behavior we want would be:
AutoReqProv: no PreReq: lsb >= 3.1
You can also fine-tune the requirements to a subset of the full LSB, say "lsb-core-ia32" for example. To implement this type of dependency you can use something like this in the .spec file:
# LSB dependency section %ifarch i386 i486 i585 i686 athlon PreReq: lsb-core-ia32 >= 3.0 %endif %ifarch ia64 PreReq: lsb-core-ia64 >= 3.0 %endif %ifarch ppc PreReq: lsb-core-ppc32 >= 3.0 %endif %ifarch ppc64 PreReq: lsb-core-ppc64 >= 3.0 %endif %ifarch s390 PreReq: lsb-core-s390 >= 3.0 %endif %ifarch s390x PreReq: lsb-core-s390x >= 3.0 %endif %ifarch x86_64 PreReq: lsb-core-amd64 >= 3.0 %endif
One more restriction that should be taken into account is that only gzip compression is allowed for RPMs. So make sure that content of your package is not compressed with bzip2 or lzma.
RPM Checking
Among different LSB tests, there is a tool named lsbpkgchk that verifies a package and its contents conform to the LSB specification. The tool can perform checks against any released LSB version higher or equal to 3.0. lsbpkgchk is included in the Linux Application Checker and is executed against any rpm package given to it.
Installing Your Application in the Right Place
Software developers and Independent Software Vendors (ISVs) have differing ideas about the right place to install applications and software packages. Some prefer to install in /usr/bin/ or /usr/local/bin/, and others prefer the /opt/ directory. Your preferences might vary depending on whether you have a UNIX System V, Berkeley Software Distribution (BSD), or GNU/Linux background. These unpredictable variations cause file and directory naming conflicts that sometimes prevents software installation, removal, and upgrades.
The Filesystem Hierarchy Standard (FHS) standard, referenced by the LSB, outlines guidelines and defines requirements for file and directory placement. The FHS promotes the interoperability of applications, system administration tools, development tools, and scripts. The FHS explains in detail the content and purpose for each of the primary directories. The following figure shows the FHS-specified directory structure.
Figure 1. Base filesytem hierarchy specified by the FHS
In addition to the FHS, the System V Application Binary Interface [ATT 1990], the Intel Binary Compatibility Standard V.2 (iBCS2), the Common Operating System Environment (COSE), the Linux Standard Base (LSB), and the UNIX community in general have already established the /opt/ directory for add-on software. The following list is a compilation of best practices for installing applications:
|
| Note |
|---|---|
|
For the following list, package is the product name of an application and provider is the LANANA registered vendor name. |
- The applications of the base operating system, or "the Linux distribution", are the only ones allowed to be installed in the /sbin/, /bin/, and /usr/ directories.
- System administrators who build packages from source (either source packages (srpms) or tape-archives (tar)) should install in the /usr/local/bin/ directory, and must avoid the temptation of installing in the system directories.
- Add-on binary-only packaged applications must be installed in the /opt/package/ or /opt/provider/ directory. For example, the binary executables should be found in their respective /opt/provider/bin/ directory.
- Manual pages for applications must be located in their respective /opt/package/share/man/ or /opt/provider/share/man/ directory. Non man page documentation should be located in their respective. /opt/package/share/doc/ or /opt/provider/share/doc/ directory.
- Host specific configurations for /opt/ binary executables should go in the /etc/opt/package/ or /etc/opt/provider/ directory (all host-specific system configurations reside in these directories).
- Variable files in a package, or files that change during the normal course of system runtime, go in the /var/opt/package/ and /var/opt/provider/ directories.
|
| Note |
|---|---|
|
Exceptions can be made to these rules if it is necessary for a package to install or create files elsewhere. For example, if a package creates a new device, it installs in the /dev/ directory. |
|
| Note |
|---|---|
|
The system administrator should create a separate disk partition for the /opt/ filesystem, and end-users should add /opt/package/bin/ and /opt/bin/ to their PATH environment variable. Usually the end-user's shell will find applications in their respective /opt/package/bin/ directories; however, the system administrator may have created symbolic links or wrapper scripts in /opt/bin/ for each package. |
Package Naming
To avoid conflicts between native distribution packages and LSB conformant packages, a naming scheme was specified. All LSB compliant packages begin with "lsb-". If the name of the package contains only one hyphen then the name must be assigned by the Linux Assigned Names and Numbers Authority. If the name of the package contains more than one hyphen then the portion of the package name between first and second hyphens must either be an LSB provider name assigned by the LANANA, or it may be one of the owners' fully-qualified domain name in lower case.
As all init scripts live in the same directory a similar scheme has been specified to avoid clashes between init scripts for packages. The LSB specification states init scripts can be in one of three namespaces:
- Assigned namespace
- This namespace consists of names that only use the character set [a-z0-9]. These names must be reserved through LANANA.
- Hierarchical namespace
- This namespace consists of scripts names that look like this: [hier1]-[hier2]-...-[name], where name is again taken the character set [a-z0-9], and where there may be one or more [hier-n] components. [hier1] may either be an LSB provider name assigned by the LANANA, or it may be owners' DNS name in lower case, with at least one period character ["."].
- Reserved namespace
- This namespace consists of script names that begin with the character "_", and is reserved for distribution use only. This namespace should be used for core packages only, and in general, use of this namespace is highly discouraged.
Init Script Naming
The LANANA Init Script names are used by LSB-compliant applications and distributions when naming init scripts placed in the /etc/init.d directory. Alternatively, it is also possible to use a script name that begins with your fully qualified Internet domain name or your LSB provider name.
Cron Script Naming
The LANANA Cron Script registry defines a reserved list of script names to be used in the /etc/cron.d directory in an LSB runtime environment. Alternatively, it is also possible to use a script name that begins with your fully qualified Internet domain name or your LSB provider name.
Example: Packaging and Installing an Application
The following example shows how to package and install a fictional software suite called widgets according to LSB packaging specifications. The widgets-1.2-3.spec RPM configuration file is used to package the software for the /opt/ directory. The %files directive (line 17) is followed by a list of pathnames which should be packaged. The Prefix tag (line 8) is how the package is made relocatable. The value of the tag defines the part of the path that can be varied at installation time.
|
| Note |
|---|---|
|
For real-life examples of constructing a conforming packages, please refer to the Rpm Examples page at the Linux Foundation wiki. |
Example 1. RPM Spec File for Widgets
# |
- Build the RPM package widgets (widgets-1.2-3.i486) as shown in the following example, using widgets-1.2-3.spec as the input file. You can use RPM to build and produce a source package file (widgets-1.2-3.src.rpm) and a binary package file (widgets-1.2-3.i486.rpm) from this input.
Example 2. RPM Build Widgets
# rpm -ba /usr/src/redhat/SPECS/widgets-1.2-3.spec |
- Install widgets on the system from the binary package (widgets-1.2-3.i486.rpm ) using the following command:
Example 3. RPM Install Widgets
# rpm -i /usr/src/redhat/RPMS/i486/widgets-1.2-3.i486.rpm |
widgets is now installed in /opt/whizbang/bin/.
- Run widgets from the command line using the following command:
Example 4. Run Widget
$ /opt/whizbang/bin/widget |
- As the system administrator, create a symbolic link to /opt/whizbang/bin/widget from /opt/bin/widget, and to /opt/whizbang/lib/libwidget.so from /opt/lib/libwidget.so. Per the FHS, this cannot be done at post-install automatically because the package does not own the /opt/bin/ directory domain. Only the system administrator has the authority to make a global configuration that may impact other applications.
Example 5. Manually Symbolic Link Widgets
# ln -s /opt/whizbang/bin/widget /opt/bin/widget |
The symbolic link will make it easier for the end-user to run widgets.
Figure 2. Simple Packaging.
- Uninstall the widgets-1.2-3 RPM package, and reinstall it in an alternate location in the /usr/local directory using the following commands:
Example 6. RPM Relocate Widgets
# rpm -e widgets-1.2-3 |
The system administrator should not forget to fix any manual symbolic links that may have been made in /opt/bin/.
Advanced Packaging
It has been demonstrated that add-on binary-only package applications are to be installed in the /opt/package/bin/ and /opt/provider/bin/ directories. The basics on how to create a relocatable RPM package, how to build it, and its flexibility has been demonstrated by being able to override the default /opt/ destination and selecting an alternate location. Now look at more advanced scenarios where packaging multiple products, packaging for multiple architectures, packaging for multiple versions of a product, or any combination thereof are being performed.
Packaging Multiple Products
Using the WhizBang example of this chapter, what if you wanted to ship another product called "gadgets"? To support multiple products by one vendor, then they should all be based off of the /opt/provider/package/ directory. Since the LANANA registered WhizBang owns the /opt/whizbang/ directory, then the most common two ways that directory can be used are to share the bin and lib subdirectories or to keep them separate in their own /opt/whizbang/widgets/ and /opt/whizbang/gadgets/ subdirectories. If they are kept separate, then symbolic links or wrapper scripts in /opt/whizbang/bin/ can be redirected to /opt/whizbang/widgets/bin/ and /opt/whizbang/gadgets/bin/. In either case, /opt/whizbang/bin/ should be configured into the end-user's PATH environment variable.
Figure 3. Packaging Multiple Products
Packaging for Multiple Architectures
To simultanously support both 32-bit and 64-bit PowerPC versions of widgets on a PPC64 system, then they need to be segregated in their own respective architecture subdirectories such as /opt/whizbang/widgets/ppc32/ and /opt/whizbang/widgets/ppc64/. The system administrator could setup a default PPC32 or PPC64 behaviour by creating a symbolilc link from /opt/whizbang/widgets/ppc32/bin/ back to /opt/whizbang/widgets/bin/, or /opt/whizbang/widgets/ppc32/lib/ back to /opt/whizbang/widgets/lib/. In either case, /opt/whizbang/widgets/bin/ should be configured into the end-user's PATH environment variable.
Figure 4. Packaging for Multiple Architectures
Packaging Multiple Product Versions
To simultaneously support multiple versions of same products, then they need to be segregated in their own respective version subdirectories such as, /opt/whizbang/widgets/v1/ and /opt/whizbang/widgets/v2/. The system administrator could setup a default v1 or v2 behaviour by creating a symbolic link from /opt/whizbang/widgets/v1/bin/ back to /opt/whizbang/widgets/bin/ or /opt/whizbang/widgets/v2/lib/ back to /opt/whizbang/widgets/lib/. In either case, /opt/whizbang/widgets/bin/ should be configured into the end-user's PATH environment variable.
Example 7. Symbolic Link Widgets during Post Install
%post |
Figure 5. Packaging Multiple Product Versions
Packaging Multiple Versions of Multiple Products for Multiple Architectures
To simultaneously support multiple versions of multiple products on multiple architectures, then they need to be segregated in their own respective subdirectories such as /opt/whizbang/widgets/v1/ppc32/ or /opt/whizbang/gadgets/v2/ppc64/. The system administrator could setup a default v1 or v2 and/or PPC32 or PPC64 behaviour by creating a symbolilc link from /opt/whizbang/widgets/v1/ppc32/bin/ to /opt/whizbang/widgets/bin/. In either case, /opt/whizbang/widgets/bin/ should be configured into the end-user's PATH environment variable.
Figure 6. Packaging Multiple Versions of Multiple Products for Multiple Architectures