[lsb-discuss] RPM build tool

Wichmann, Mats D mats.d.wichmann at intel.com
Sun Aug 31 07:35:44 PDT 2008

Sorry, somehow I missed this, it was sitting unread in my box.
I think Stew may have already responded the way I'm going to
but I'll toss this out anyway:

Theodore Tso wrote:
> On Tue, Aug 12, 2008 at 01:27:26PM -0600, Wichmann, Mats D wrote:
>> or maybe it's an indication that rpm, which has already dealt with
>> all of this stuff and is well proven, should be encouraged instead of
>> dismissed.  it's one thing if we have people with existing packaging
>> mechanisms who want to use those on all their products, including
>> Linux ones.  but if they're going to adopt a tool that's Linux-only
>> anyway,  as this one would be,  then why not stick with rpm?
> The argument has been that some ISV's are willing to deal with
> platform specific packaging tools, since they have today for Windows,
> Solaris, AIX, Macos, etc.
> However, they don't want a tool which takes over how they build
> things, and RPM fundamentally assumes that you start with a source
> tarball plus patches.  This means that in order to use RPM you have to
> rototill your entire build proess.  This is especially bad for ISV's
> who want to build out of source code management system, and where the
> sources are big enough that needing to package them all up into a
> gigundo tarball just to make RPM happy is not what they are looking
> for.  (Or some ISV's built several binary components out of separate
> SCM repositories, and then combine them together when producing a
> release --- this can be espeially problematic given how rpmbuild
> forces all projets to fit into the same procrustean bed.)

While rpmbuild can do all this, you don't have to take advantage
of all those features if you don't want.  In our own application
battery builds, we've essentially taken the build through the
"make install" phase entirely outside of rpmbuild, installing to
an empty tree.  We then point rpmbuild at this tree to package it
up - and nothing more.

As an example, I've attached the entire specfile for the rsync
Application Battery build.  See that that the sequence of
unpack-patch-build-install that *can* be driven by rpmbuild
was not, in this case.  We've caused those steps to happen
previously, installing to what rpmbuild will expand
%{pkgroot}/%{name} to (and yes, this means you do have to
coordinate this value between the specfile here and the
stuff that drives the actual build).   Now the only active
part that rpmbuild picks up on is that it should package up
everything in the %files list, as found in that path we just
referred to.  Pretty simple, really - no rototilling involved
if your existing build process already can "install to a clean
location".  In the rsync build we did previously, we've
counted on the GNU-style syntax "make prefix=SOMEWHERE install"
to do the right thing; of course other builds may accomplish
this in a different way.

Summary: A program for synchronizing files over a network.
Name: lsb-rsync
Version: 3.0.0
Release: 1.lsb4
Vendor: Linux Foundation
Packager: Appbat Team <lsb-appbat at linux-foundation.org>
License: GPL
Group: Appbat/file transfer
Buildroot: %{pkgroot}/%{name}
AutoReqProv: no
PreReq: lsb >= 4.0

LSB conforming version of rsync.  Rsync is a program for bringing remote
and host files into sync very quickly. Rsync is fast because it just
sends the differences in the files over the network instead of sending
the complete files. Rsync is often used as a very powerful mirroring
process or just as a more capable replacement for the rcp command.
Rsync is added to the LSB Application Battery primarly to demonstrate
the use of networking.







%attr ( -   bin bin ) /opt/lsb/appbat
%attr ( -   bin bin ) /etc/opt/lsb/appbat

* Tue Mar 18 2008 Stew Benedict <stewb at linux-foundation.org>
- bump to 3.0.0

More information about the lsb-discuss mailing list