Andrew Lentvorski wrote:
There are lots of things which feed into a build. Compiler versions,
tools versions, os versions, etc. *All* of these need to be tracked and
linked to a version number in order to create a build.
And this is one of the other problems I am pondering: We have a machine
which I call "the build machine". When we compile the SRPM's into RPM's
for installation on the appliance a great big chunk of the build machine
becomes part of those RPM's and thus the appliance. Libraries get linked
in, the gcc on the build machine affects the binaries, etc. Every so
often we have to apply security fixes or other changes to the build
machine. So the build machine that built the code today won't be the one
that build the code from before.
Is this a problem? How big of a problem? I haven't decided yet.
We have all of the SRPM's in the VCS (whichever VCS it ends up being) so
we could theoretically re-create the software we shipped at any point in
time except for the fact that this software has to be built somewhere
and that somewhere will affect the end result. The current solution to
this in the old build system is to keep the iso's generated for each
version of the OS. On one hand this seems silly since the VCS should be
able to reproduce it and it takes up disk space and results in these big
.iso files we have to manage but on the other hand it seems to be the
only guaranteed way to be able to reproduce the system and disk space is
cheap.
Here is how I am currently thinking the build process will work:
We will build our distro using the same method and build system that
CentOS uses to build their distribution and we will track their
distribution closely. They do something similar to what the client wants
to do: They take the original RedHat sources, make their changes (mostly
in the form of re-branding but the idea and methodology are the same),
create a patch off of the pristine source, and then apply that patch
in building their RPM. I have talked to Johnny Hughes, leader of the
CentOS project, and gotten some feedback on this plan and he agrees
that this is a good way for us to go.
First we will do a yum upgrade of the current build machine off
of a CentOS mirror on the Internet to make sure it is totally up to
date.
Then we will download and install onto the new development machine all
of the applicable SRPM's which correspond to the RPM's installed on
the box.
Then we can put any additional SRPM's needed by our distro into the
repository as well. We may have to consult a list of current
RPM's in our distro to make sure the new system has all of the
equivalents. So the repository will contain everything needed to operate
the build machine and everything needed to operate our distro. Under no
circumstances will they end up running different versions of the same
thing so that we can be sure that RPM's built on the build machine are
perfectly compatible with our distro.
Then we will pull the pristine tarballs from the SRPM's SOURCES
directories and put them aside (we will never be modifying these) in
another directory. They each come from RedHat/CentOS with a unique
name and version number. Then we will check the entire remaining
source tree into version control. We put the tarballs aside because
checking big binary files which we aren't going to be changing anyway
into version control really bloats up the version control database for
no good reason. The actual RPM spec files contain references to the
names/versions of the tarballs anyway. When the rpm is built it will
automatically retrieve the tarball from the tarball repository using
a tool called spectool which comes with a package called rpmdevtools.
We will run our own private mirror of CentOS which will track/rsync
the public mirror of the SRPM's and we will run our own private RPM
repository where we will manually copy in any updates or modified
RPM's which are generated off of our SRPM's.
After the above yum update of the build machine the yum.conf on the
build machine will be made to point to this private repository. If a
new security update comes out for something like dhcp which we have
not modified at all then we can simply replace the SRPM in our
repository with the new SRPM, check it into version control, and
generate an RPM off of it which goes into our RPM repository. We can
yum upgrade the build machine and it will get the new dhcp. Any future
builds of our distro will automatically get the same version. If it is a
security update for a package which we have modified we will have to
manually merge our changes with the new SRPM. Then we build the RPM
off of that, put it into the RPM repository, yum upgrade the build
machine and any future versions of our distro get the same one.
Since the yum.conf on the build machine points to our private RPM
repository which is generated off of our version controlled SRPM
repository the build machine is always guaranteed to match the
system it generates so that when we compile things to make our
RPM's we know we aren't mixing things up. Our distro will be a
subset of the software in the repository as is the build machine. So
our distro and the build machine all come from the same software
repository and they are upgraded in sync with each other. RPM's in the
repository are always built from our source RPM's which are all
version controlled.
For CentOS-5, building an ISO uses the anaconda runtime and the
buildinstall command. Here is documentation on the buildinstall
command:
https://fedoraproject.org/wiki/Anaconda/BuildInstall
When building the ISO a list of the packages required for our distro are
supplied and those are pulled out of the repository and the ISO is
built. This ISO can then be used to install new systems or upgrade old
systems.
We can also do PXE boot network installs of our distro off of our RPM
repository which is much faster than burning CD's and doing CD
installs if we ever have to install a bunch of our distro at
once.
--
Tracy R Reed Read my blog at http://ultraviolet.org
Key fingerprint = D4A8 4860 535C ABF8 BA97 25A6 F4F2 1829 9615 02AD
Non-GPG signed mail gets read only if I can find it among the spam.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
