Re: Should we package BioConductor TFBSTools? [Was [libtfbs-perl] 04/08: Add upstream's notice of deprecation to the package's description.]

[Steffen Möller <steffen_moeller@gmx.de>]

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