hi Roland, all, On Thu, 28 Mar 2019, Haas, Roland wrote:
> Here is my reasoning for removing the suggestion for now (if you > disagree, please create a ticket here: > https://bitbucket.org/einsteintoolkit/tickets which will ensure that > the suggestion is not lost with the wiki page), I've put a somewhat reformatted version of my suggestion on bitbucket: https://bitbucket.org/einsteintoolkit/tickets/issues/2239/getcomponents-avoid-useless-downloads > Looking at all downloaded data (using the same definitions as above), > the total amount of downloaded data is around 360MB, giving a possible > download speedup of 30% which, while potentially noticeable, is not > very large given the effort required to remove the tarballs. I've tried to clarify that download volume (and compile time) are convenience aspects of the proposal. The question of well-structured and organised software development (prefer native packages) is more important. There are much too many science packages needed for any individual to check all of these thoroughly. I wouldn't like to analyse a scientific (numerical) bug that I detect in an ET-level package and after a few days of analysis find that it's a result of a known bug that has been fixed in the Debian stable version, which I could have trivially chosen to use myself in preference to the ET default version. There are also security, portability, reproducibility, and licence compatibility bugs that I'm much less likely to detect myself. And as I've put on the bitbucket ticket: if the ET community have customised versions of openmpi, openssl, GSL, fftw3 that are in some ways better than the upstream ones, then these should be proposed for checking and merging upstream. Cheers Boud _______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
