On Fri, 2012-11-09 at 18:46 +0100, Stijn De Weirdt wrote: > >>> The framework was unaffected, the bugs were limited to particular > >>> software packages. > >> > >> Nice. What is your recommended "authoritative" way to track such > >> changes? > >> > >> I am having my view at this one now which is not always most > >> readable summary: > >> https://github.com/hpcugent/easybuild-easyconfigs/commits/master > >> and I understand this addresses the zlib version fighting I > >> noticed, too! > > > > I'd say checking the commit log is indeed the best way to go. Only a > > limited number of commits are involved, and I tried to make the > > commit messages clear. > > It might be easier to get a complete overview if the "merged pull request" was just completely removed and replaced by the description. > > > >> Furthermore, some packages -including the bioinformatics ones we > >> have contributed- may have a little bit difficulty to build > >> straight out of the box. I suggest to play clean and lean for the > >> v1.0 release and put them aside for a next release. (ie. if you see > >> any suspicion of trouble, better put it in a queue for later). We > >> do not need to be so strict for next releases, just this first > >> one. > > > > They seem to be building fine on our end, although we have had some > > issues with the MUMmer easyblock you contributed, see > > https://github.com/hpcugent/easybuild-easyblocks/issues/8 . > > > > There will be several easyblocks that are not perfect in the current > > release, but I don't see that as a reason to exclude them. We want to > > get feedback, and if people think we're building something in the > > wrong way, we want to get feedback on it, or even better, to let them > > contribute fixes for our mistakes. So, I'd leave those in, especially > > since the build works fine in a clean regtest. > if you are aware of issues with configs or blocks that prevent > functional usage, we shouldn't ship them at all. > > stijn
In this mummer case, the libraries get built and installed, but the scripts not. So it is valid as a dependency to get AMOS working, but it's not fully functional... (And actually AMOS and MUMmer require perl, which is not in EasyBuild yet)
