[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Action needed for R-pkg Uploaders



Hi Charles,

Am Thu, May 09, 2024 at 08:44:10AM +0900 schrieb Charles Plessy:
> Le Tue, May 07, 2024 at 02:53:40PM +0200, Andreas Tille a écrit :
> > > 
> > > Charles Plessy <plessy@debian.org>:
> > >  r-bioc-genomeinfodb
> > >  r-bioc-genomeinfodbdata
> > >  r-bioc-genomicalignments
> > >  r-bioc-hdf5array
> > >  r-bioc-iranges
> > >  r-bioc-matrixgenerics
> > >  r-bioc-rtracklayer
> > >  r-bioc-s4arrays
> > >  r-bioc-s4vectors
> > >  r-bioc-summarizedexperiment
> > >  r-bioc-xvector
> > >  r-bioc-zlibbioc
> > >  r-cran-biocmanager
> > >  r-cran-epitools
> > >  r-cran-genetics
> 
> Hi Andreas,
> 
> I have a strong interest in Bioconductor and want to work on the next
> transitions(s).  I put myself uploader of some of the core Bioc packages
> as I am keen on following closely their evolution.

Thanks a lot.

> On the other hand, I am trying to routine-upload r-cran packages.
> Sometimes it goes well, but sometimes I inspect the diff and I see that
> I would need to update the Files-Excluded field to remove new HTML
> documentation (which is becoming more prevasive),

In this case I observed way more false positives from lintian than real
problems.  I override those false positives with the additional comment:

   # See lintian bug #1017966

which you can find in nearly 100 r-{bioc,cran} packages.  If it turns
out that there is really an issue with JS in html docs I simply fire up
this script:

   https://salsa.debian.org/r-pkg-team/maintenance-utilities/-/blob/master/r-exclude-doc?ref_type=heads

which in most cases does what I want.  Nilesh once tried to restore
those docs as you can see for example in r-bioc-qtlizer.  While it meets
high packaging standards I'm not fully sure whether there are many users
using those docs.  Probably you will know better whether this extra
effort is rectified.  If yes it might make sense to adapt dh-r in a way
that this is done automatically if the doc was removed before.

> update names and years
> in debian/copyright and run the process again.

I admit I do not update years in d/copyright.  Simon McVittie once
described the role of d/copyright files as "write-only"[1].  IMHO in the
case of R packages we can safely assume it fulfills this role since we
can be safe from CRAN side that we are dealing with Free Software.  So
please call me lazy here but I do not update the d/copyright file (MRs
from those who consider this important are welcome).
 
> I am sorry to say that I finally realised that my appetite for copyright
> management has fell so low that it may explain why I was so inactive in
> the past years.

Does the paragraph above help you in this aspect?

> When I encounter such a package, I just give up for the
> whole day unless it is strictly necessary for something important that
> depends on it.  I think that we need to either automate, or eventually
> convince the Debian community at large that 1) for everything that comes
> from CRAN and Bioconductor, the upstream DESCRIPTION file is enough
> user-visible copyright documentation and 2) their HTML documentation is
> build with Free Software and we should tolerate it in Debian.

Before you brought up this topic here what you call "the Debian
community" was happy with the way it went.

Kind regards
    Andreas.

[1] https://lists.debian.org/debian-devel/2022/02/msg00177.html 

-- 
https://fam-tille.de


Reply to: