On 06/11/2015 02:36 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)? Two things: (1) The C and C++ compilers are special. They are part of an "implementation" and so it makes sense that they be provided by something like "gcc" or "gcc-c++" which provide everything you need to compile a standards conforming C or C++ application. Therefore programs that are written in C or C++ would BuildRequires: gcc or BuildRequires: gcc-c++. If in the future we support more than one system compiler then we may wish to replace them all with more generic c_lang or c++_lang provides that are satisfied by one or the other implementations. (2) The rest of the BuildRequires. When it comes to autoconf, automake, libtool, sed, awk, grep, I actually think Fedora needs systemtap or strace based tooling to: (a) Look at all the tools that were executed in a build. (b) Recommend a set of BuildRequires: to the user. That way you can keep your BuildRequires up to date and tweaked relatively easily. The tooling can be run to output to your koji logs so you can see exactly what your overall set of BuildRequires are. Then the developer keeps their list of BuildRequires up to date, small and relevant. This helps in distribution bootstrap CI efforts by minimizing BuildRequires, and helps reduce buildroot sizes and disk usage during builds. > 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. In my opinion this calls for tooling to help developers with BuildRequires. The corollary being that one might run such tooling over a bootstrap of the distribution and compare BuildRequires to package spec and see what differences there are if any. Then with this information you can make an informed choice about the need for build-essentials. Otherwise build-essentials will get cargo-culted into every spec file and we're back to a defined buildroot standard based on build-essentials which will grow over the years. All the things RCM wanted to avoid. Cheers, Carlos. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
