Hi, There are also a lot of dependencies to applications that in my opinion don't need a specific toolchain, but just need to be available. Maybe don't add these to a specific toolchain or version, but a generally avaible toolchain (dummy?). Also, now dependencies are really strict on version, while this is not always necessary. Maybe having something like '>' and/or '<' for version dependencies might help to focus on applications that really need updating.
Maybe this is already discussed and decided on a long time ago or maybe this will cause other problems. Regards, Erik On Fri, Nov 24, 2017 at 10:48 AM, Åke Sandgren <ake.sandg...@hpc2n.umu.se> wrote: > It's fairly simple. > > Use whatever is already available for the selected toolchain. Don't > forget to check the git develop branch and any pending PRs when deciding > on versions. > > On 11/24/2017 10:16 AM, Joachim Hein wrote: > > Hi, > > > > Because of interoperability of software, I see an increasing need to fix > software versions beyond what is included in the actual toolchains. I am > discussing standard dependencies, like jpeg libraries, HDF5, netcdf, curl. > So, unless there is strong reasons (e.g. bugs), packages build with a > certain toolchain (e.g. foss/2017a) should use a “preferred version” for > standard dependencies. Using the latest and greatest, which is what I did > some time ago has downsides in the form of module load conflicts. > > > > The question is how would one administer this (selection of version(s), > communication between contributors, …), without driving the administrative > burden even higher. I like to put this for discussion among the regular > contributors. > > > > Best wishes > > Joachim > > > > -- > Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden > Internet: a...@hpc2n.umu.se Phone: +46 90 7866134 Fax: +46 90-580 14 > Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se >
