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 >>> * >>> https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelines&diff= >>> 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 >> themselves)? > > 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 > group 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: https://fedorahosted.org/fpc/ticket/540 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 programs >> 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 packagers 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 in comps. > the packages defined in the comps groups define the minimal buildroot, which > is what gets installed when you do "mock -r <config> --init" BuildRequires > 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. Cheers, Carlos. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
