Re: New versions of some Bioconductor packages for R 3.4.0
Hi Graham,
On Sun, May 14, 2017 at 11:39:08AM +0200, Graham Inggs wrote:
> On 12 May 2017 at 02:18, Charles Plessy <plessy@debian.org> wrote:
> > as R 3.4.0 is in Unstable and as the current Bioconductor packages in Unstable
> > are from a release that does not support R 3.4.0, I think that you can upload
> > to unstable directly.
> >
> > And yes, please commit directly to SVN. Use "Team upload" in the changelog if
> > you are not Uploader and do not want to become so.
>
> Thanks for the explanation. I have uploaded new versions of
> r-bioc-annotationhub, r-cran-matrixstats and r-bioc-biocgenerics to
> unstable. The latter two being prerequisites of r-bioc-aroma.light
> and r-biocparallel respectively.
I have created a dependency graph of most of the bioc packages here:
https://anonscm.debian.org/viewvc/debian-med/trunk/packages/R/r-bioc-000-dependency-scheme/3.3/
The makefile created a PNG but the ditaa file is perfectly readable in
your favourite editor ... in case this might help spotting further
dependencies. Please note that this is true for BioConductor 3.3 and
might be invalid for 3.4.
> I still need to tag the releases in
> SVN, and will upload r-bioc-aroma.light and r-biocparallel soon.
Fine. That's perfectly welcome. I think we should upgrade the other
BioConductor packages since it is to be expected that when uploading new
versions of base packages other rdepends might become erroneous if not
even unusable. I never did an a formal transition for these package due
to their low popcon usage but strictly speaking this is what needs to be
done.
> Updating r-bioc-s4vectors requires new versions of r-bioc-iranges,
> r-bioc-genomicranges and r-bioc-genomeinfodb.
> It appears that in the latest version, upstream have split the
> GenomeInfoDb package into GenomeInfoDb and GenomeInfoDbData.
> I'll start preparing the packaging for a new r-bioc-genomeinfodbdata
> package in SVN tomorrow, unless I hear otherwise.
I do not intend to stop you uploading these packages. Feel free to
add yourself to Uploaders if you consider this appropriate.
BTW, if you might wonder why SVN is used: The motivation is that
usually R packages are brain dead simple in packaging in most cases
while storing upstream code might occupy a lot of disk space. Since our
packaging policy includes upstream source storage I considered this a
bit overkill. I was somehow considering to have a common Git repository
for all R packages keeping only all their debian/ dirs. Some teams have
this kind of policy but I was afraid about the work to adapt the policy
text about it and not to forget the code that gathers SVN and Git data
for the Blends tasks pages. So it remained as is. If you seriously
consider maintaining some BioConductor pages and would prefer Git feel
free to migrate from SVN to Git if this might match your workflow
better.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: