Re: New versions of some Bioconductor packages for R 3.4.0
On Tue, May 16, 2017 at 01:17:09PM +0200, Graham Inggs wrote:
> On 14/05/2017 12:08, Andreas Tille wrote:
> >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.
>
> Thanks, much of it still seems to be relevant.
> How did you create it?
You mean the ditaa file itself? Using my favourite text editor.
Or the relations? Try and error what is needed as Build-Depends.
> It would be good to update that for Bioconductor 3.5
> which was released last month.
Yes. I noticed this but intended to work on this past Stretch release.
Usually I'm working on the ditaa file when working down the dependency
try packaging the new versions and stumbling about changes.
> >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.
>
> I am monitoring Ubuntu's Proposed Migration tracker [1].
> Ubuntu are gating on autopkgtest results, which has been helpful in
> identifying what needs to be rebuilt or needs updating.
> Unfortunately, some packages have always failed their autopkgtests, so don't
> help with identifying regressions. Once r-base/3.4.0-1 itself has migrated,
> I will look at its dependencies.
Your contribution is more than welcome.
> >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.
>
> That makes sense. I am happy with the status quo.
OK - so it can stay as is. :-)
Kind regards
Andreas.
> [1] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#r-base
--
http://fam-tille.de
Reply to: