On 06/12/2015 12:11 PM, Dennis Gilmore wrote:
On Thursday, June 11, 2015 08:36:38 AM Florian Weimer wrote:
> On 05/21/2015 10:11 PM, Jason L Tibbitts III wrote:
>> The BuildRequires section of the guidelines has been revised; the
>> exceptions list is gone. The release engineering folks are free to
>> define the buildroot and rpm is free to change its dependency list.
>> * https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2
>> 413629&oldid=409506 * https://fedorahosted.org/fpc/ticket/497
> Can we get a build-essential package instead that requires everything
> that is needed to get a working C and C++ compiler, and run most
> autoconf/automake/libtool-generated scripts (but not the autotools
Can you please help me to understand the problem you are trying to solve? what
is different to "dnf install @buildsys-build" other than a package vs a comps
The recent policy changes mean that developers have to take action to fix
broken spec files. Comments like those above are essentially a request,
and the request from our developers is going to be:
"Now that the buildroot can contain almost nothing, what do I need to
require in order to build C or C++ applications?"
"Do I have to figure out every possible command that autoconf might call
and include it in my BuildRequires or is there some magic meta prodives
I can use?"
To answer this question for C and C++ development I have filed this FPC:
And while the pedantic answer is "BuildRequire and Require on whatever
you need", that is in my opinion insufficient guidance for Fedora packagers.
> In my opinion, it is a bad use of developer time to track what
> exactly are called from ./configure, and how these programs match
> sed/grep/coreutils. It would also give us a central place where we can
> fix breakage due to missing packages in build roots because a
> significant fraction of packages got a build-required package through an
> indirect dependency.
can you describe the issues and breakages you are talking about, or point me
at some examples. the buildroot does not often break. but in the scenario
you are talking about fixing may be difficult without being able to build the
package that has the fix.
At present there is no breakage, but as proactive Fedora packagers Florian and
I have kicked off the conversation to say "What will happen?" "What do
need to do to keep their spec files building?"
I am trying to understand what you see as broken and how this would
fix it. as
opposed to how things are currently done.
What is broken is that we have no standard set of meta requires to say things
like "I need a C development environment" e.g. BuildRequires: c-devel.
Worse is when it comes to autoconf and determining exactly all the commands
possibly run by the upstream configure. We need a tool that in some ways helps
compute the set of tools required from a build.
right now we have the build group defined in koji and buildsys-build
the packages defined in the comps groups define the minimal buildroot, which
is what gets installed when you do "mock -r <config> --init"
get installed on top of it. then the build is done
That's not at issue. What's at issue is how do packagers keep their spec files
building given the policy change enables the buildroot to contain almost nothing.