The Linux Foundation

 

Become an Individual Member

BuildRPMHeader

From The Linux Foundation

Contents

Building a rpm header from scratch, without using rpm

Purpose

ISVs tell us building an rpm is too hard. Decision is to make a tool that will build up an rpm as:

header data + cpio archive

or

header data + arbitrary files

With the possibility to be able to manipulate tags, as well as add %pre/%post scripts etc. "header" in this context is really "leader + signature + header".

Alternative?

It would seem that building just a skeleton spec like we do in the appbat, perhaps via some wrapper scripts to make things easier, and then running rpmbuild with a known rpmrc to control the output format could also solve this issue.

Existing projects?

I did a fair amount of searching via Google, but did not really come up with anything that fits this niche. Most of the things I found that interface with the rpm API are for manipulating the rpm database. I also looked at using the rpm API directly to build up the rpm, but it seemed like I might as well be using rpmbuild if I go down that road. librpm and friends are not in LSB, and building an LSB compliant executable that uses the API starts to bring in a bit of baggage. I did dabble with this briefly and was able to create a file with empty header data, but did not pursue it any further.

Seems my predecessors in LSB also worked on this: mkpkg. Checked this out too, but it looks like it's in even less of a complete state than where I'm at when I found out about it.

Creating a header file

A preliminary makelsbpkg perl script has been created that can make a standalone rpm package from a directory of files. (7/24/08 - this is out of date now, the current build requires some CPAN modules and the rpm package should be used)

Also packaged as an rpm.

And the bzr branch.

Example usage:

[stew@norris rpmtool]$ ./makelsbpkg foobar pkgroot/foobar
[stew@norris rpmtool]$ rpm -Kvv foobar-1.0.0-1.i486.rpm
D: Expected size:      1717808 = lead(96)+sigs(100)+pad(4)+data(1717608)
D:   Actual size:      1717808
foobar-1.0.0-1.i486.rpm:
    MD5 digest: OK (0b7780fd3fe7fdc436b5c2b6b1bddba0)
[stew@norris rpmtool]$ rpm -qip foobar-1.0.0-1.i486.rpm
Name        : foobar                       Relocations: (not relocatable)
Version     : 1.0.0                             Vendor: LSB
Release     : 1                             Build Date: Thu 10 Jul 2008 05:31:00 PM EDT
Install Date: (not installed)               Build Host: norris.e-artisan.org
Group       : Stuff                         Source RPM: foobar-1.0.0-1.src.rpm
Size        : 5673418                          License: GPL
Signature   : (none)
Packager    : Stew Benedict
Summary     : This is the foobar12 package
Description :
LSB rpm builder test package
[stew@norris rpmtool]$ rpm -qlvp foobar-1.0.0-1.i486.rpm
drwxr-xr-x    2 stew    stew                0 Jul  9 14:31 /opt/foobar
drwxr-xr-x    2 stew    stew                0 Jul  9 14:31 /opt/foobar/bin
-rwxr-xr-x    1 stew    stew          5661754 Jul  9 14:31 /opt/foobar/bin/Xvfb
drwxr-xr-x    2 stew    stew                0 Jul  9 14:05 /opt/foobar/lib
-rwxr-xr-x    1 stew    stew             5940 Jul  9 14:05 /opt/foobar/lib/libXtst.so
drwxr-xr-x    2 stew    stew                0 Jul  9 14:05 /opt/foobar/man
drwxr-xr-x    2 stew    stew                0 Jul  9 14:05 /opt/foobar/man/man1
-rw-r--r--    1 stew    stew             5724 Jul  9 14:05 /opt/foobar/man/man1/Xvfb.1
[stew@norris rpmtool]$ sudo rpm -ivh foobar-1.0.0-1.i486.rpm --nodeps
Preparing...                ########################################### [100%]
   1:foobar                 ########################################### [100%]

(nodeps due to requiring lsb >= 4.0)

Some tags are hard coded or created at buildtime, while others are usable configurable via command line switches.

lsbpkgchk has some complaints about package at the moment, but it does not fail.

Source directory looks like this:

[stew@norris rpmtool]$ find pkgroot/
pkgroot/
pkgroot/foobar
pkgroot/foobar/opt
pkgroot/foobar/opt/foobar
pkgroot/foobar/opt/foobar/bin
pkgroot/foobar/opt/foobar/bin/Xvfb
pkgroot/foobar/opt/foobar/lib
pkgroot/foobar/opt/foobar/lib/libXtst.so
pkgroot/foobar/opt/foobar/man
pkgroot/foobar/opt/foobar/man/man1
pkgroot/foobar/opt/foobar/man/man1/Xvfb.1

Tarball is here. I'm currently suppressing /opt, and I'll need to think about how to handle this. Pkgchk of course complains if it's included.

The package is currently able to be installed/removed on ia32 with rpm.

Local testing with various arbitrary sets of files, with as many as 30,000 files compromising 600Mb or so were able to be built into an installable rpm package that passes lsbpkgchk (about 4 mins build time for the big fileset).

User configurable tags

Currently the user can set a number of tags via command line options:

[stew@norris rpmtool]$ makelsbpkg -?
./makelsbpkg version 0.1 - LSB Project RPM build tool

usage: ./makelsbpkg packagename [cpio file or source directory] (options)
       source directory structure should be something like:
                          opt/lanana-name/all-my-files-and-dirs

user definable options (package tags, quote multiple words):
                             --version
                             --release
                             --summary
                             --description
                             --vendor
                             --license
                             --packager
                             --group
                             --arch (only noarch is valid)

other options:
                             --debug
                             --help|-?

So you can do something like this:

makelsbpkg --verbose foobar pkgroot/foobar --license "Artistic" --version "1.2.3" \
--release "5" --group "Fake Stuff" --package "Sammy Davis" --vendor "Las Vegas" \
--summary "none of your beeswax" --description "this is one crazy package"
prebuilding leader...
building signature...
building header...
building (or processing) payload...
processing payload files...
resuming header...
finishing header index...
building signature data store...
writing to package file...
wrote foobar-1.2.3-5.i486.rpm
[stew@norris rpmtool]$ rpm -qip foobar-1.2.3-5.i486.rpm
Name        : foobar                       Relocations: (not relocatable)
Version     : 1.2.3                             Vendor: Las Vegas
Release     : 5                             Build Date: Fri 11 Jul 2008 02:34:19 PM EDT
Install Date: (not installed)               Build Host: norris.e-artisan.org
Group       : Fake Stuff                    Source RPM: foobar-1.2.3-5.src.rpm
Size        : 5673418                          License: Artistic
Signature   : (none)
Packager    : Sammy Davis
Summary     : none of your beeswax
Description :
this is one crazy package

Remaining Issues

lsbpkgchk has some complaints over the resulting rpm, although it does not fail. I opened bug 2218 one one issue that pkgchk complains about, which doesn't seem to be required by the spec (RPMTAG_ARCHIVESIZE or SIGTAG_PAYLOADSIZE). pkgchk also seems to always complain about "SIGTAG_MD5 calculated value doesn't match expected value" for *any* rpm, even when rpm -Kvv says things are OK (bug 2225). Also pkgchk gets out of sync in some way processing the files and starts reporting mismatches in file size, inode, md5sum, dev, etc. Turns out this part is a mismatch between the file listings in the header store (/opt/foo/bar) vs the listing in the cpio archive (opt/foo/bar). If I format the header store listing like the cpio archive, pkgchk gets happier, but the package gets installed by rpm relative to `pwd`. Cpio intentionally suppresses the "./" in copyout.c, but pax can make an archive with this format, like 4.x rpm packages have. This resolves the pkgchk complaints and makes a package installable relative to /.

Have not done anything yet with regards to %pre/%post scripts. (now complete 7/24/08)

Add the ability to read the user definable tags from a (xml?) file. (now complete 7/24/08)

Make a man page (complete 7/24/08)

Review the source directory concept of: pkgroot/opt/lanana-name/[directory structure like the final install] and see if there's something more flexible we can do there


[Article] [Discussion] [View source] [History]