Subject: Re: rpm makefile patch for Linux/PPC
sterwill@abisource.com
Date: Wed Jan 26 2000 - 14:28:15 CST
Logan Hall wrote:
> so we have to find a way to parse this correctly or find a way to get rpm to give it
> to us.
I think Gary's correct--we're using RPM in a way it was not intended to
be used. As I've said before, we do this so we have the same executable
(done by the same build pass) for all packages for a build host. This
means the "AbiWord_d" executable will be the same for the static tarball,
dynamic tarball, and RPM for that one host that builds all three.
This is not how RPM wants to run, and changing would be good. Doing so
means re-structuring the build process. Right now one master "make"
takes care of EVERYTHING, and when it's done, you have a dist directory
full of packages (of all types, tar.gz, .rpm, .deb, .slp--whatever you
requested with ABI_DIST_TARGET).
Part of this process is pulling our spec file template through sed to
replace numbers with the current version, then copying that file
into /usr/src/redhat/SPECS, building one large tarball of the
source with objects and binaries in it, putting that in
/usr/src/redhat/SOURCES, and calling RPM. RPM runs its own "make"
inside the sandbox it makes, make finds nothing to do (since all the
objects are there), then RPM moves onto the install, package, clean
stages.
That's how it currently works.
A goal of an automated build process is still important. When I
wrote the RPM packager, all I knew about RPM was from the text of
the Maximum RPM PostScript file I had, and RPM's manual pages.
An alternative that would mesh well with automated builds would be
to give up the guarantee of identical binaries on a single host
and find another way to get the spec file up to date, then let
RPM do everything. The Makefile distribution targets will need to
be changed. In fact, if we do it this way, "make distribution" will
never be called, but some of its logic will need to move elsewhere.
This is a large job and requires a lot of testing.
Are there any RPM wizards out there willing to work towards
getting nicer RPM packages?
-- Shaw Terwilliger
This archive was generated by hypermail 2b25 : Wed Jan 26 2000 - 14:28:16 CST