On Wed, Feb 11, 2015 at 2:32 AM, Stuart Barkley <stua...@4gh.net> wrote: > I've been looking at easybuild for a little while now and it appears > to be a suitable framework for a good portion of our needs.
Welcome to EB! > My cluster does not have direct access to the Internet so I can't use > any of the automated download procedures. I actually consider this a > feature in that I eventually know exactly what software is running and > that nothing was downloaded and installed that wasn't intended. What is stopping your users from copying other software to your cluster and running it? Or using a ssh portforward/socks proxy to get internet on your cluster? > Dependencies/source package downloads: > > I think I eventually used "--dry-run --robot" and grepped the output > to determine the full dependency lists and create individual 'eb > --stop=fetch --force' commands for every package dependency. I also > used something like this to determine an internal build order so I > didn't need to --robot 50 packages which would all churn and fail on > the same dependency. We could create an `--fetch-only` option that doesn't stop on a failed download. > Some questions: > > How do people deal with software with frequent updates (java) or > security issues? Do you rebuild and remove old packages? For the security sensitive package, we use the OS provides ones (openSSL, glibc, ...) and let the OS update them. > Is there any planned support (or something I'm missing) for allowing > someone else to use an existing easybuild installation (including > toolchains and other packages) to build a test/prototype package? I > would like to have other staff be able to build local test packages > off of the production toolchains and be able to give me a set of > proposed/working .eb files for final build. This is similar to the > above beta question, except I don't expect others to be able to > maintain their own easybuild installation (and don't want them writing > into the production installation). You can use a different `-installpath=` for the test packages? If the production toolchains are in the module path, they will be used. > Wish list (maybe for hack-a-thon): > > Don't automatically create $HOME/.local/easybuild (or any other top > level directory). Too many times I forgot to specify my configuration > file name or fumble fingered something and ended up with a mess of > files where I didn't intend. Requiring the top level directory to > already exist prevents a misconfigured easybuild from writing a bunch > of stuff for later cleanup. The error message should be clear about > the directory name so that a simple copy/paste can be used to create > the missing directory when it is truly missing. I don't agree here. Almost all Linux programs will create their own directory under $HOME without asking. It's the proper thing to do. If you have troubles forgetting the specify certain options, add them to the config.cg file? Or export them as bash variables if the change from location to location. > Process for removing a package. It is probably fairly simple, mostly > deleting the installation tree and the modules files. Dependencies > might be tricky (indicating all the dependencies and refuse to remove > would be fine). This is on the wish list for quite some time: https://github.com/hpcugent/easybuild-framework/issues/1000 Ward
