Re: Semi-automatic upgrades to new upstream versions (Was: Upcoming Bioconductor 3.7 release, developed for R 3.5.0)
Hi Dylan,
On Tue, Apr 24, 2018 at 11:03:21AM +0200, Dylan Aïssi wrote:
> 2018-04-24 8:52 GMT+02:00 Andreas Tille <andreas@an3as.eu>:
> >> I think after further testing of
> >> others and thorough inspection of the results we might move it over to
> >> the dh-r package.
> >
> > What do you think about this?
>
> Thanks for this, yes this will be useful as well for the
> create_README.source script. I have just two comments:
:-)
> 1. For the routine-update script:
> I think it's not necessary to check if debian/tests exists to add
> Testsuite: autopkgtest-pkg-r into d/control.
> If I remember well, when both are present (Testsuite:
> autopkgtest-pkg-r and some tests into debian/tests), only tests into
> debian/tests are executed (I will check it).
If you have both you get a lintian warning about useless
Testsuite: autopkgtest-pkg-r
However, as I recently learned on debian-python list you can use
debian/tests/control.autodep8
instead and than both is possible. May be you verify whether my
understanding is correct and than it would help if we always add
Testsuite: autopkgtest-pkg-r
and use control.autodep8 if we have some specific test for a package.
> As I am working to improve autopkgtest-pkg-r (and make useless common
> tests in debian/tests), the "Testsuite: autopkgtest-pkg-r" field could
> always be present into d/control so we will only have to remove tests
> from debian/tests in favor of autopkgtest-pkg-r.
I was motivated to get rid of a lintian warning - probably the test
itself was OK.
BTW, I'm currently experimenting with adding dh-update-R to the
routine-update script which needs a patch to dh-update-R to keep the
formatting as done by cme. I have a rough hack created with my poor
Perl knowledge. I'll test with some more packages and will puch then
but will ask for further inspection to not break anything.
> 2. For the create_README.source script:
> As suggested by lamby [1], it could be useful to have a more
> machine-readable format than the current README.source.
Muhaha, what a bug report. You try to create more work for us. :-)
Honestly, IMHO that way of documenting binary data field is just a means
to increase the bureaucracy inbetween maintainers of R packages and
ftpmaster. I do not see the slightest use for any of our users and I
would rather love to see that file go for good than to spent even more
time on something where I totally fail to see its use. The only reason
why this file exists was to convince ftpmaster to let binary files slip
through. It is obviously redundant documentation since I have proven by
create_README.source that it can be auto generated. What you are
requesting inside the bug report is whether the autogeneration works.
> It should not a big deal but we have to agree on which format do we
> want, then just let your script do the job to fill the file.
Please leave me out of this discussion and make sure there will be a
somehow working script to call. I would really love to avoid a
conversion process from one useless file to another. I do not think
that this bureaucracy is in the interest of our users which should
have priority.
> Maybe we can take this opportunity, to make this file more general and
> not only useful for RData files. i.e. by adding information about
> other binary data, I'm thinking about feather data files [2] for
> example.
No idea what this is and not really motivated to check.
Kind regards - but despite my obvious displeasure, thanks anyway to try
to get things straight and correct which in general is a very good
feature
Andreas.
> [1] https://bugs.debian.org/891231
> [2] https://cran.r-project.org/package=feather
--
http://fam-tille.de
Reply to: