Dne 19.2.2018 v 17:16 Dennis Gilmore napsal(a): > 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 So we removed Perl from buildroot, but there is already something which consumes the saved DL and install size of Perl and on top of that it adds additional 10 MB to DL and 50 MB to installation? Well done ... > >> >> >> 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? We are not able to remove gcc from buildroot, how we could have something like "learning bots" doing out job? Vít
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
