El lun, 19-02-2018 a las 10:56 +0100, Vít Ondruch escribió: > > > Dne 19.2.2018 v 00:52 Dennis Gilmore napsal(a): > > El vie, 16-02-2018 a las 12:56 +0100, Jan Kurik escribió: > > > 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. > > > > What is the expected savinsg in time for builds? > > It depends who is your target audience. These were the numbers for me > last time we discussed this specific question: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje > ct.org/message/LWC5L53CD2BLJKSF2XXZ4D57MS2WXEJL/ > > > BTW it is interesting, that although Perl was removed since the last > time, the minimal buildroot is bigger than it used to be and it takes > longer to install then it used to: > > Install 171 Packages > > Total download size: 128 M > Installed size: 494 M > > real 1m17,327s > user 0m55,004s > sys 0m6,176s redhat-rpm-config taht is needed has grown dependencies, as language specifc macros have moved into their own space > > > > V. > > > I realise it is hard > > to measure, however it should only be a second or two per build at > > most. Buildroot creation time is really not the slowest piece of > > the > > pipeline. There is a lot of other areas that I feel would net a > > bigger > > win. For instance machine learning bots to do package reviews and > > package maintainenece, where changes like this could be > > automatically > > built in to the package maintainece lifecycle. None of that addresses the questions, is this really a worthwhile use of time, are we not better off investing in automated management of package maintainence and lifecycle rather than minor tweaks to existing process and fixing subjective time consuming things. If we automated 80% of the basic lifecycle tasks will we not all be better off and have time to work on things we find much more interesting? Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
