Hi payerle, I believe this caveat means: If you have a naming scheme in place, and start using a new one, EasyBuild will be confused and start overwriting software made with the old module naming scheme.
e.g. You install package foo-2.0.0 in /software/Core/foo/2.0.0 You want to install bar which depends on foo-2.0.0 EasyBuild will attempt module load foo/2.0.0, find the foo module and just start building bar You now switch module naming scheme to also include the toolchain name in the module name. You want to install a new package bla with the foss toolchain and bla depends on foo: EasyBuild will attempt module load foss/foo/2.0.0 and not find it, since the module previously created is called foo/2.0.0 EasyBuild will attempt to install foo/2.0.0 but since you only changed the module naming and not the install path, it will override /software/Core/foo/2.0.0 This could also happen if you install packages manually, and not create modules that have the exact name EasyBuild is looking for. If you run reinstall --force EasyBuild will also override manually installed packges, but that's what the --force is for, you should know what you want when you use --force. Hope this helps clarifying this a bit? Regards, Jens Timmerman On 22 June 2018 at 18:26, <[email protected]> wrote: > I am investigating the use of easybuild when we roll out our next cluster. > > One concern raised was from > https://github.com/easybuilders/easybuild/wiki/ > Using-a-custom-module-naming-scheme > where it clear states that different installation prefixes are needed for > different easybuild naming schemes, or easybuild for schemeA might delete > software built with schemeB. > > I am still getting familiar with easybuild, but this suggests to me that > if I > plan to have a mix of software built with easybuild and software built > manually and/or with some other software build tools, that they would need > to > be installed in distinct software trees. E.g., if I intend to build > package > foo with easybuild, putting it in /software/Core/foo/... and I intend to > build > package bar manually, then I better not put bar in /software/Core/bar but > in > something like /software2/Core/bar. (Using > HierarchicalMNS naming scheme) > > Is my understanding of this correct? > Does this only happen if rebuild/force flag is used? > Does it only happen for the app trying to rebuild (and/or dependencies)? > --- > e.g. is it safe to have both foo and bar under /software/Core as long as I > never issue an easybuild command that would try to rebuild bar (either > directly or as a dependency)? E.g., is the foo/bar example somewhat OK, > but I > only get burned if I e.g. built foo/1.2.3 with eb and foo/1.2.4 manually? > > Is there a list anywhere of the directories that EasyBuild wants full > control > over? Is it the whole > tree rooted at --prefix, or just the source, build, software install, > module > install paths? to Would it be safe to have foo in > /software/[Core|Compiler| > MPI]/foo and bar directly under /software? >
