cAos talking documents
cAos principles and QA goals
Update work in progress - caos-1
Quick Q and A
Q: How do I get a non-root build environment working?
A: A quick lesson in using rpm (through its rpmbuild binary)
with yum, to build stuff:
But remember: Always BUILD as NON-ROOT -- Please file bugs if you cannot do so
for a given package. More information available at:
http://www.oldrpm.org/ and the resources
- Make sure your system is up to
$ sudo yum -y update
- Install the RPM package building
$ sudo yum -y install rpm-build
- Then wget, chmod 755, and run
This sets up a build directory structure for a non-root user, which
the RPM Package Management system needs.
- Get a .src.rpm -- There are lots of 'SRPM' (source RPMs,
marked by the suffix pair .src.rpm) archives in the world,
and many fine packagers.
- rpmbuild -ba that.src.rpm; some tarballs have embedded
.spec files (which are the meta-'recipe' for assembling the
contents of the tarball , its patches, configuration files, and any pre-
- Additional developmental libraries, or compilation aid programs build
environment stuff might be needed -- autoconf will tell
you; rpmbuild will tell you; yum will get it and install
it (and its dependencies) for you.
Q: How do I set up a clean build chroot?
A: A build chroot is usually a populated copy of a complete build
environment (but otherwise sparse -- see the 'thought piece' on this matter,
'reproduceable builds'; this piece is interesting, as building in a
clean buildchroot was generally considered excessive at the time it was
written), which is entered as the non-root building user, to build a
For systems running yum-2 or later, our script
can do the heavy lifting. It is presently targetted to set up a cAos-1 build
environment as the master build chroot, but is trivial to repoint to other
distributions using an RPM later than rpm-4.0.x.
Q: Okay, I have that master build chroot (whatever that is). Then what
do I do to start building?
A: For efficiency, we have adopted the practice of making a working copy of
the master build chroot, building once, retrieving the results of the build
out of the copy of the build chroot, and throwing the copy away.
This is overkill (some more sophisticated ways to the goal of avoiding build
chroot pollution exist), but we have seem packagings 'in the wild' which work
very hard to escape the build chroot.
Our script at: ftp://ftp.owlriver.com/pub/local/ORC/ORCrebuild/ORCbuildit
should offer some clues; the copy of the buildroot is actually entered
as a non-root user at the extended line toward bottom reading:
# now we build as non-root
chroot $BUILDROOT/$TEMP sudo -u builder rpmbuild $NODEPS \
-ba /usr/src/$DIST/SPECS/$j \
>> $BUILDROOT/$TEMP/usr/src/$DIST/$NAME-build.txt \
2>> $BUILDROOT/$TEMP/usr/src/$DIST/$NAME-error.txt || \
That script is tailored to produce lots of diagnostic information;
it was written to assist gathering QA information as well, per this
In drafting stage
cAos website custom code
Generate the nightly mailing on build success/failure - ORC_notify (sanitized to protect adopter's
email addresses source URL)
Writing a .spec
file -- references to 'rpm -ba' are obsolete; use
'rpmbuild -ba' in its place
Updated _Maximum RPM_
mach mailing list
Scholz' fedora buildsystem document - vserver (patched kernel)
Mandrake RPM-devel package dependencies - (local PDF)
srpmcvsimport - Import several srpms into CVS
Comments and additional editorial appreciated. Please send to:
| || ||Modified: Mon, 05 Mar 2007 14:24:49 -0500|
Copyright © 2017 R P Herrold