>> However, since the working dir for the test is the root of the extracted >> source package, we should be able to extract the R and debian package >> names directly rather than hardcoding or deriving them: >> >> rpkg=$(grep-dctrl -s Package -n '' DESCRIPTION) >> dpkg=$(grep-dctrl -s Package -n '' debian/control) >> >> and in fact, skip finding tests and vignettes in the installed >> filesystem and just find them in the source package: tests/*.R ; >> vignettes/*.Rnw - in which case we don't need to know the package R or >> debian names. > > I confirm that if you use the script for CI *only* this would work > nicely. However, I consider it a good idea to provide the user with > some test case / example use and thus I always put the script into > /usr/share/doc/<pkgname> where grep-dctrl does not work. On the other > hand I could check the directory name if all other means to calculate > the package name might fail.
I hadn't considered other uses. However, there is maybe the possibility of instead including a generic template and inserting the correct values (determined as above) at build time? However, since this would require modifying all the d/rules files, it is maybe too much engineering to squash a few copy-paste bugs which are mostly now fixed - to be added to the wishlist for debhelper-R? > [...many packages fixed...] > >> - hopefully it'll look >> in much better shape in a few days and we can see if CI is actually >> doing its job and identifying some real errors. > > Yes. Of the original list, I cound 24 (8 bioconductor and 16 cran) packages now passing (on amd64 - most are still marked failed on arm64 but I think that is just that the tests haven't re-run yet). Thanks to those that committed fixes and uploaded. > >> I'll have a better look at the "?" ones. > Etiquette question - for packages in debian-science git requiring trivial changes (eg, a missing package in debian/tests/control), is the preferred course to just go ahead and commit the fix?
