On 30 Sep 2016, at 12:00, Pablo Escobar Lopez <[email protected]<mailto:[email protected]>> wrote:
I like what Joachim suggest about the "attic" concept. Old/deprecated easyconfigs provided "as-is" but not included in the regular tests. I think I suggested something similar in one of the conf calls. About how to search in the legacy easyconfigs I would prefer a different approach . What I would suggest is that instead of skipping those ones when doing "eb --search" I would still show them when doing a regular search with "eb --search" but in case the search result comes from the "attic" print a big disclaimer saying something like "I found this legacy easyconfig in the attic but we aware that this is not tested". Or maybe in case some legacy stuff is found print a url which links to the docs sections explaining what is the attic. Hi Pablo, Thanks for your support here. I feel a need for cutting "diarrhoea“. An “eb -S foss” produces a volume of output that is creating issues. For ordinary work I will not need the legacy packages and not having them included will make the “eb -S” more useful. Looking at your argument, the alternative to my original proposal might be an option to not list “attic” items. Anyway, even nowadays I treat EB configs/block that are old as “as is” and do not report them as broken. I have seen a fair number of failures in about 1/2 year of easybuilding. I don’t even keep a record. Not worth anyone’s time I think. Best wishes Joachim My fear about not searching by default in legacy easyconfigs is that many people would skip the extra option needed to search in the legacy easyconfigs and they wouldn't notice that it's there. Many times even if the legacy easyconfig doesn't work it can be useful as a start point to write a new one so it's useful to find them easily. I know many of us are sysadmins and we like to reply RTFM but easybuild has many many different config flags and it's easy to skip this one ( even for a sysadmin ;) regards, Pablo. 2016-09-30 11:41 GMT+02:00 Joachim Hein <[email protected]<mailto:[email protected]>>: Hi Kenneth, I had a look into the notes and think some extra discussion is required on the “discontinuation business”. Not sure where to start this, so I am replying here. I occasionally get requests for “historic” and “fossile” versions of packages - not all of them totally unreasonable, e.g. API change in application. Examples include OpenFOAM and Gromacs. Prior to EasyBuild I would have said no, unless you give me a strong reason. With EasyBuild, I check whether a to the user acceptable version is in the “back catalog” and try to easybuild it. If it builds without much issue I roll it out. If it breaks I am not worse off than without EasyBuild. Typically I build with the “old” machinery of the time (that is what it was tested with) - installing a legacy GCC and OpenMPI in EB is typically easy. I think here are two big selling points of EB, which we perhaps not even push enough. * Better user experience - many requests for legacy versions can easily be supported. It is typically easier to just build it instead of discussing with the user. * Building software with a tried and tested software stack gives stability against bugs introduced in the latest version So, how do you plan to do the discontinuation? Removing toolchain versions will break everything that builds on that toolchain. Keeping them as “unsupported” seems the way forward to me. That is, it is still available in some form but no longer tested and fixed. If they still work, good, if they are broken: work around it. Introducing an “attic” type concept might be an idea. Depreciated packages get to the attic. A typical “eb -S” would not show them, but e.g. an extra “attic” or “antique” option would. Best wishes Joachim On 29 Sep 2016, at 18:36, Kenneth Hoste <[email protected]<mailto:[email protected]>> wrote: notes are available at https://github.com/hpcugent/easybuild/wiki/Conference-call-notes-20160929 Next conf call is planned for Wed Oct 12th 5pm CET, cfr. https://plus.google.com/events/cir0grjke0kbfutgmgp2v9nfm3s On 27/09/16 21:03, Kenneth Hoste wrote: Dear EasyBuilders, The next EasyBuild conf call is planned for *Thursday* September 29th 2016, 5pm CET; see also https://plus.google.com/events/c8tqca652anjfqblifjam5q9s6k . (just this once, I've planned it on a Thursday rather than a Wednesday due to an agenda conflict) Topics I have in mind include: * (very early) outlook to EasyBuild v3.0: default config changes, (minor) backwards-incompatible changes * deprecating toolchains: what & how * see also https://github.com/hpcugent/easybuild/wiki/Deprecated-toolchains * update on support for RPATH (WIP) * https://github.com/hpcugent/easybuild-framework/compare/develop...boegel:rpath?expand=1 * Q&A Suggestions for additional topics are welcome. Please let me know if you're planning to attend this conf call. More information about the EasyBuild conf calls is available at https://github.com/hpcugent/easybuild/wiki/Conference-calls . regards, Kenneth -- Pablo Escobar López HPC systems engineer sciCORE, University of Basel SIB Swiss Institute of Bioinformatics http://scicore.unibas.ch<http://scicore.unibas.ch/>
