#306 Prohibit conditionalizing payload on architecture
Closed: Fixed None Opened 7 years ago by toshio.

While debating the relative merits of using %{_isa} in BuildRequires, Panu brought up the fact that conditionalizing BuildRequires is a much bigger issue as it changes what is in the payload of the srpm depending on which architecture it is built on. This can affect whether the built srpm contains all of the necessary files to be rebuilt on any architecture:

https://lists.fedoraproject.org/pipermail/packaging/2013-June/009229.html

Proposal:

Packages '''MUST NOT''' have SourceN or PatchN tags which are conditionalized on architecture. For instance:

{{{

Incorrect

%ifarch ppc64
Patch0: build-fix-for-ppc64.patch
%endif
}}}

Conditionalizing Source and Patch tags by architecture makes it so the built SRPM may not contain everything needed to rebuild itself on a different architecture (If the example above was built into an SRPM on x86 then the SRPM would not contain Patch0. This would mean the SRPM would not contain all the files needed to be built on a ppc64 computer.)

The best strategy for things like this is to write code that can be built on any architecture (using conditionals in the code to handle incompatibilities between architectures if necessary). The second best strategy is to use spec file conditionals only when utilizing the value of a Source or Patch tag like this:

{{{
%prep
[...]
%ifarch ppc64
%patch0 -p1
%endif
}}}

I can't find an existing Guideline section where this belongs so this would be added to the Guidelines in a new section. Maybe: "Conditionalizing builds for Architecture" added after the "Architecture Support" section: http://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support


yeh, it's same theory for the _isa ... so I'm +1 on any sane wording.

This seems pretty obvious, so +1 from me. You can certainly conditionally unpack a source file or apply a patch, but you shouldn't conditionally include either in a spec.

However, as to conditional build dependencies, I do have to wonder if there's some situation that simply isn't possible to do any other way. Such as requiring some package to build on a specific arch which is only available on that arch.

+1 from me, obvious rule. Ensures an src.rpm can be rebuilt on any arch regardless of which arch it was built on.

Replying to [comment:3 tibbs]:

However, as to conditional build dependencies, I do have to wonder if there's some situation that simply isn't possible to do any other way. Such as requiring some package to build on a specific arch which is only available on that arch.

This is fairly possible. You can have an optional build-time dependency. And that dependency is available only on some architectures. I heard about virtualization and java stuff.

Also I can imagine this case with pcre. pcre contains a JIT compiler that is implemented only for some architectures. If the compiler had split from pcre (and there is an JIT upstream for the pcre upstream), then there would be a new !BuildRequires on that. However the dependency would exists only on some architectures, thus there would have been an architecture-qualified !BuildRequires.

Draft approved (+1:6, 0:0, -1:0)

Historical note: tibbs rightly pointed out that in the initial description (above the draft proper), I wrote the wrong words for the sentence. It should read:

[...]Panu brought up the fact that conditionalizing SourceN: and PatchN: is a much bigger issue as it changes what is in the payload[...]

Writeup for this seems to have slipped through the cracks. I've now added the new section to the guidelines. Announcement Text:

"""

Added a guideline: "Packages MUST NOT have SourceN or PatchN tags which are conditionalized on architecture." This makes sure an srpm has all of the files needed to rebuild itself. Note that this change is not intended to prevent packages from conditionally applying patches or sources during the build. That remains a valid practice.

"""

Login to comment on this ticket.

Metadata