[Rpm-maint] [PATCH] Allow '--short-circuit' for '-bb'
mschmidt at redhat.com
Thu Jun 17 15:50:50 UTC 2010
Short-circuiting has been intentionally only allowed for the %build and
%install stages, but not for the final building of the binary package.
The supposed reason for having this limitation is that it's necessary to
ensure the repeatability of builds.
For instance, Jeff Johnson in 2003 said
> This is a design feature of rpm, guaranteeing that binary packages
> result from a complete build, not from hacking on intermediated stages.
> So, no, there are no plans to implement this (non-) fetaure.
> PITA, yes. But the guarantee is important.
A bit more recently Tom "spot" Callaway supported this view
> Hm. FWIW, my opinion is that people shouldn't be short-circuiting
> builds like you're describing, it only opens the door to
> non-reproducable builds. Obviously, others disagree with that. :)
Indeed, there are others who disagree.
I believe the limitation should be removed because:
1. It prevents some valid use-cases.
When developing a patch for a program, it's useful to be able
to test the modified program in the natural environment,
i.e. as it is installed in the system from an RPM package.
The developer often goes through several iterations of the patch
before he gets it right. The necessity to do a full rebuild of the
program on every iteration in order to get the RPM is prohibitively
2. It fails to achieve its declared purpose (repeatability of builds).
The source package does not by itself sufficiently define the
conditions for a repeatable build, because a different toolchain
may be used or there are other versions of the build dependencies.
After all, that's why we have mock+Koji and other distributions'
3. It breeds ugly workarounds.
In both email threads I referenced there was a post from someone who
suggested a more or less kludgy workaround.
One amazingly efficient and trivial-to-use workaround is even
included in Fedora:
Take a look at its source if you enjoy nasty LD_PRELOAD tricks.
(No offence meant to Lubomir. I admire his hack and am grateful for
it. And I'm sure he'll be glad when shortrpm will no longer be
4. The danger it's supposed to prevent is overstated.
Distributions do proper builds from sources anyway so they don't have
to care. I don't know who the "many many people who attempt to abuse
it" spot wrote about are. Reasonable people will understand that
they should not publish shorted builds. Malicious people have
zillions of other ways to create trojaned binary RPMs.
Apparently Mandriva has been shipping a similar patch for years (there's
a mention of a "one-liner from Mandrake" in the 2003 thread, and they
still have rpm-4.6.0-rc1-bb-shortcircuit.patch today).
The world failed to end.
BTW, Jeff J. must have changed his mind at some point, because rpm5
allows short-circuiting of -bb.
doc/rpmbuild.8 | 5 +++--
rpmqv.c | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/doc/rpmbuild.8 b/doc/rpmbuild.8
index 6ad5bf1..f2f16f9 100644
@@ -170,8 +170,9 @@ used standalone, eg. "\fBrpmbuild\fR \fB--rmspec foo.spec\fR").
Skip straight to specified stage (i.e., skip all stages leading
-up to the specified stage). Only valid with \fB-bc\fR
+up to the specified stage). Only valid with \fB-bc\fR, \fB-bi\fR
+or \fB-bb\fR. Useful for local testing only. Packages built this
+way should not be distributed.
Embed a GPG signature in the package. This signature can be used
diff --git a/rpmqv.c b/rpmqv.c
index be2707c..6104e2f 100644
@@ -660,6 +660,8 @@ int main(int argc, char *argv)
ba->buildAmount |= RPMBUILD_PACKAGEBINARY;
ba->buildAmount |= RPMBUILD_CLEAN;
+ if ((ba->buildChar == 'b') && ba->shortCircuit)
ba->buildAmount |= RPMBUILD_INSTALL;
ba->buildAmount |= RPMBUILD_CHECK;
More information about the Rpm-maint