On Fri, Feb 16, 2018 at 03:41:35PM +0100, Igor Gnatenko wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Fri, 2018-02-16 at 14:27 +0000, Daniel P. Berrangé wrote: > > On Fri, Feb 16, 2018 at 12:56:32PM +0100, Jan Kurik wrote: > > > Proposed System Wide Change: Remove GCC from BuildRoot > > > https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot > > > > > > > > > Owner(s): > > > * Igor Gnatenko <ignatenkobrain at fedoraproject dot org> > > > > > > > > > Removing gcc and gcc-c++ from default buildroot in Koji and mock. > > > > > > > > > > > > == Detailed description == > > > Since beginning of Fedora, gcc (and gcc-c++) are installed in every > > > buildroot. Times have changed and nowadays many of packages are not > > > written in C/C++, they are written in Python, Ruby, Node.js, Go, Rust, > > > OCaml, Perl and so on so they don't need to have C/C++ compiler. > > > Installing gcc and gcc-c++ takes time so if we remove it, we can > > > improve build times for many of the packages. > > > > > > > > > == Scope == > > > * Proposal owners: > > > Remove gcc, gcc-c++ from build group in Koji and from buildsys-build > > > group in comps. > > > > > > * Other developers: > > > Maintainers should follow guidelines and add BuildRequires: gcc if > > > they need it during build (this guideline exists for long time). > > > > I feel like this is something that many many many packages will not > > have present. For a long time it was acceptable to omit BuildRequires > > for stuff that was in the default build root, and while the C/C++ > > packaging guidelines do say you need BR: gcc, I expect most packagers > > have never noticed this changed. > > > > IOW, if we remove gcc/gcc-c++ from the build root, *before* fixing > > up packages we're going to create a huge pile of rebuild failures. > > > > Can we please do something here to identify which packages likely have > > missing BR: gcc and automatically fix up the specs, rather than creating > > 100's of failing packages and then waiting weeks in a broken state for > > maintainers to fix them up. > > There is no simple way of doing this. Also as other thread mentioned, people > hate automated changes... So for this one we need every single packager to fix > their packaging and not to fix it in automatic way. For the few people who complain about the automated changes, there's a largely silent group would just welcome it. I would think we can detect it easily enough by looking for packages which contain ELF binaries. Those are going to require GCC except in the rare case that it used clang, and even then adding the BR: gcc would be harmless. You can further detect C++ by seeing if the ELF binaries linked to libstdc++ Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
