[Rpm-maint] [PATCH] Allow '--short-circuit' for '-bb'

Panu Matilainen pmatilai at laiskiainen.org
Mon Jun 21 13:10:49 UTC 2010

On Thu, 17 Jun 2010, Michal Schmidt wrote:

> 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
> (http://www.redhat.com/archives/rpm-list/2003-October/msg00037.html):
>> 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
> (http://lists.rpm.org/pipermail/rpm-maint/2008-June/002136.html):
>> 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
>   expensive.

Well, this is the only reasonable use-case that I'm aware of.

> 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'
>   build systems.

You're reading too much into the "repeatability of builds" here. Of course 
a src.rpm alone cannot guarantee it's rebuildable as is everywhere you 
might throw it. It's about recording every step it took to build a 
package in the spec/src.rpm, so given the same conditions (this 
is what the buildsystems are about), the package is rebuildable and not 
failing because somebody forgot to manually apply a patch or some other 
tweak after interrupting the build one way or the other.

> 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:
>   https://admin.fedoraproject.org/pkgdb/acls/name/shortrpm
>   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
>   necessary.)
> 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.

It's not about distro folks (who should know better), reasonable people 
or even malicious people. Just recently somebody requested for 
short-circuit to be enabled for binary and source. Apparently they were 
using this to apply security patches to packages, ie run 'rpmbuild -bp', 
apply some patches (via whatever mechanism) and then -bb --short-circuit 
to complete and then distributing the packages. And they had no idea this 
was somehow not such a good idea.

If rpmbuild lets -bb be shortcircuited with no strings attached, somebody 
WILL think "oh this is handy" and use it everafter without giving a second 
thought whether it was ok or not as "rpm let me so it must be ok".

/me thinks I've said this before, more than once, but...

I would consider applying a -bb/-bs --short-circuit enabling patch if the 
patch causes the resulting package to be "poisoned", requiring some extra 
switch to be installable. The developer in case 1) who knows what [s]he's 
doing knows to use --i-know-i-am-using-shortcircuited-builds and in case 
such packages somehow end up in circulation (rpms have a funny way of 
floating around to unexpected places) others will at least know this isn't 
mean for "production" as it fails to install by default.

Again, the point is not protecting against malicious users or whatever, 
it's more of a philosophical (or even educational if you like) issue.

 	- Panu -

More information about the Rpm-maint mailing list