Hello, On 21.10.17 10:11, Charles Plessy wrote: > Le Sat, Oct 21, 2017 at 08:08:49AM +0200, Andreas Tille a écrit : >> when reading this commit log: Should we package Bioconductor TFBSTools? >> >> This would need at least a hand full of Bioconductor depencencies but >> usually it is quite straightforward and can be easily done via >> >> dh-make-R --team med --test run-unit-test >> >> plus editing d/copyright a bit. > Hi Andreas, > > my gut feeling is that we should better concentrate on packages more at > the core of Bioconductor, or gaining tration to move towards the core, > for example MultiAssayExperiment, unless we get a specific request.
I keep using the BioConductor-provided installation routines myself all the time. They work. Most of the time. Those who work with BioConductor always want the very latest developments and while those of us using testing or unstable may be fine, IMHO BioConductor is mostly pointless to have in the release. So, we either find a way to automate the backporting or we should not have the packages as part of our distribution in the first place. What we should have are all those C libraries that BioConductor links against, together with the header files to allow for the compilation of the BioConductor packages. And maybe a virtual package named "BioConductor-dependendencies-for-biocLite" would help. But otherwise ... I tend to think that we should just acknowledge that the BioConductor folks are doing a good job. We could also think about extending the BioConductor install routines to become aware of Debian underneath and the packages it offers, so the one or other recompilation (takes a while and extra resources) could be spared. With respect to a packaging triage that I understand Charles to insinuate, I tend to think we should embrace the emerging standardization of workflows and pick a subset of those workflows that we then support as good as we can. I keep changing my mind on weather this also involves the management of e.g. genomic data or not. Best, Steffen
