m (1 revision(s)) |
m (PackagingDrafts/BuildRoot moved to Archive:PackagingDrafts/BuildRoot: (no revisions since import from MoinMoin May 2008) Appears to already be applied to Packaging:Guidelines#BuildRoot_tag) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 47: | Line 47: | ||
At one point, the second was a mandatory value, but it is now left to the packager to decide. If unsure, simply pick the first. | At one point, the second was a mandatory value, but it is now left to the packager to decide. If unsure, simply pick the first. | ||
[[Category:Archived packaging guideline drafts]] | |||
Latest revision as of 21:39, 21 February 2009
"has been too much talk about this topic. This topic is not a rebel topic. This topic is !BuildRoot, Bloody !BuildRoot"
BuildRoot Guidelines
Author: Axel Thimm
Revision: 0.04
Initial Draft: Thursday Feb 22, 2007
Last Revised: Thursday Feb 27, 2007
Introduction
!BuildRoot is the path that is intended to be used during the %install step to populate a directory with the directories and files appearing in %files sections (with the buildroot value stripped).
While this seems like a straightforward item, it has created too much confusion and polarisation in the Fedora Project. One of the reason is that many people think the proposed !BuildRoots are not adequate and others feel too patronized by them.
History
There was an id -un based buildroot as a suggestion in the guidelines ("preferred"). This lead to some reviewers to block submission because they considered "preferred" to be a MUST instead of a SHOULD.
Later this buildroot was converted to a mandatory buildroot, which created even more animosity because making something mandatory means that it should be working sanely. But all that buildroot did was cover a rare corner case of multiple users building the exact same package on the same system concurrently. The more probable case of building for several architectures concurrently (like x86_64 and i386) was not covered by this current "mandatory" buildroot. Promoting something that is flawed in this way to a mandatory status is A Bad Thing (TM).
Finally a !BuildRoot was suggested to use mktemp which would satisfy all of the above, but by design does not have different %install and %clean invocations match up, thus leaving populated buildroots behind if rpmbuild is not used with --clean. This was considered by some to be a lesser evil than all the previous buildroots, but again has different camps, arguing in favour or against.
Impact
There is no known issue of !BuildRoot bugs in a package until now. The real issue is that this consumes large amounts of discussion time of packagers, reviewers, people on the packaging commitee and people on fesco w/o any sane result. This is probably the least productive large discussion item, besides maybe %{buildroot} vs $RPM_BUILD_ROOT.
There are two ways to overcome this: Allow more than one buildroot to get more people agreeing with the guideline, or to explicitely drop the mandatory part. We assume that packagers do sane things, and there is no guideline to not use "rm -rf /etc", so why should packagers not be handled as grown-ups when choosing a "!BuildRoot:" tag as well?
Proposition
The guidelines should soften the requirement and give a couple of possible choices for a !BuildRoot:
BuildRoot tag
The !BuildRoot value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane !BuildRoot.
The recommended values for the !BuildRoot tag are (in descending order of preference) :
%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%{_tmppath}/%{name}-%{version}-%{release}-root
At one point, the second was a mandatory value, but it is now left to the packager to decide. If unsure, simply pick the first.