Bug 617538 - make rpmbuild depend on minimum build set
Summary: make rpmbuild depend on minimum build set
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-23 11:52 UTC by Gordan Bobic
Modified: 2010-08-10 12:19 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2010-08-10 12:19:27 UTC

Attachments (Terms of Use)

Description Gordan Bobic 2010-07-23 11:52:59 UTC
Description of problem:
sqlite2 source rpm spec file has an incomplete BuildRequires list. This probably goes back quite a long time. It needs to also include at least the following:

Version-Release number of selected component (if applicable):

Steps to Reproduce:
On a system without cpp and gcc-c++, run:
rpmbuild --rebuild sqlite2-2.8.17-5.fc12

Actual results:
configure will fail due to the lack of cpp and cc1plus binaries. This should be caught by the BuildRequires line in the spec file.

Expected results:
rpm should report missing dependencies before ever attempting to initiate the build.

Comment 1 Alex Lancaster 2010-07-23 15:59:56 UTC
(In reply to comment #0)
> Description of problem:
> sqlite2 source rpm spec file has an incomplete BuildRequires list. This
> probably goes back quite a long time. It needs to also include at least the
> following:
> cpp
> gcc-c++

gcc-c++ (and cpp which is automatically pulled in when gcc-c++ is installed) is considered part of the minimal set of BuildRequires that is installed automatically in the koji build system, and should therefore not be explicitly included (otherwise almost all packages would have to install the same list):


If you look at almost all packages across the Fedora Collection you would find the same set of omissions.

"BuildRequires" only need to consider packages outside the core set required for Fedora's build system.  If you are building a package outside that environment (i.e. "rolling your own" via rpmbuild), then it's up to you to install the minimum build environment as described in that list.

Comment 2 Gordan Bobic 2010-07-23 16:05:51 UTC
That is, IMO, wrong. The BuildRequires should be relative to the _minimal_ install, not some arbitrary "build system".

Comment 3 Alex Lancaster 2010-07-23 17:25:34 UTC
(In reply to comment #2)
> That is, IMO, wrong. The BuildRequires should be relative to the _minimal_
> install, not some arbitrary "build system".    

That's the policy, not my policy, you can take it up with FESCo, but I believe it was debated fairly early on, you can search the wiki archives.  The issue is that it would involve a repetition of packages across *all* spec files in the distribution.   Also, the "minimal" install probably wouldn't include rpmbuild.  

A solution might be to make rpmbuild "Requires" the minimal build set as described in that link.  That way if you install rpmbuild it would automatically install the needed gcc-c++ etc.   I'll re-open this bug and redirect to that package.

Comment 4 Jeff Johnson 2010-07-24 13:24:20 UTC
Re comment #2: The issue is what are the elements that constitute _minimal_ set,
and that is arbitrary and changes over time no matter what.

The issue is _NOT_ whether all necessary dependency assertions have been added.

E.g. your example failure case
    rpmbuild --rebuild sqlite2-2.8.17-5.fc12
also implicitly assumes an intent to compile elements of sqlite2 that
need gcc-c++ which (in many cases) has switches and/or
AutoFu to build either maximally (needing gcc-c++) or minimally
(not needed gcc-c++).

Self-consistent assertions are ultimately based on arbitrary policy choices
about what features are desired (wrto sqlite2 needing gcc-c++) and what elements can be
assumed in a _minimal_ build set (which atm almost certainly includes cpp
and likely includes gcc-c++ based on a heuristic that little is
gained by adding explicit assertions everywhere).

You're likely better off arguing for a definition a smaller _minimal_
set without cpp/gcc-c++ (which instantly implies that the BR's you wish
to see _ARE_ necessary) than arguing from an example like sqlite2
because the overall per-distro cost/benefit is clearer when talking
about what should be in the _minimal_ install set.

Comment 5 Gordan Bobic 2010-07-25 09:00:24 UTC
If the minimal build set is arbitrary and incomplete, then what is the point of having BuildRequires in the first place? If you have to see what the build breaks on due to missing dependencies and manually install it, then BuildRequires is rather pointless.

In terms of sqlite2 and the type of build - the type of build is whatever the default build set up in the spec file is. This is what BuildRequire should be set for.

The way I see it, the main purpose of BuildREquires is that it should be simple to set up a script that checks dependency requirements based on BuildRequires, and initiate large-scale package rebuilds with dependencies (e.g. for distro-rolling or large-scale updating). The goal shouldn't be avoiding BuildRequires being 80% similar for all packages - it should really be a full list of all packages that are required for the src.rpm to build. In that sense, even setting up an empty meta-package for the sake of pulling in "default-build" dependencies would be a horrible bodge, because it would still be arbitrary and subject to change. If you make the BuildRequires exhaustive, the problem goes away.

I understand that the "minimal" install set is somewhat arbitrary, too, but you have to start somewhere, and it seems to me it would at least be a better place to start than an arbitrary set plus another arbitrary set.

Comment 6 Jeff Johnson 2010-07-25 11:32:13 UTC
If you want to "start somewhere", a bug against RPM ain't the place,
and discussing the deep meanings of "minimal" isn't going to solve
anything soon.

Reassign the bug if you wish.

Comment 7 Panu Matilainen 2010-08-10 12:19:27 UTC
In Fedora, the kind of "minimal build set" you're talking about exists as a yum group, to ensure the "minimal build set" just do:
# yum groupinstall buildsys-build

Some repositories use a metapackage instead of a group to accomplish the same. Both methods have their pros and cons, if you want to see a change to how this is done in Fedora I suggest bringing it up for discussion on fedora-devel list. rpm-build already has all the dependencies it needs to create barebone packages, everything beyond that belongs elsewhere.

Note You need to log in before you can comment on or make changes to this bug.