hmisc and r-cran-rms testing migration blocked

Andreas Tille tille at debian.org
Tue Jan 24 17:35:58 UTC 2017


Hi,

On Tue, Jan 24, 2017 at 10:53:43AM -0600, Dirk Eddelbuettel wrote:
> 
> | > which should be writable to any DD and do a Team upload / NMU at your
> | > preference or send me a patch you consider the best solution.
> | 
> | https://anonscm.debian.org/git/debian-science/packages/r-cran-knitr.git/commit/?id=5e342fd1f88595b3779ef1fe6dbce768508b8e4b
> | 
> | It seems wrong that these JS packages are *build* dependencies,
> | there are not used during the build.
> | 
> | They should instead be Suggests or Recommends, and that would also make
> | r-cran-knitr available on armel again.
> 
> Seconded. But it's not my package so ...

Well, we have seen in the past that we have diverging opinions about
"ownership" of packages.  I can't repeat less that if you do a

    dch --team

it is perfectly fine.  Its actually the point of team maintenance that
more than one person can (and should) fix issues.

Back to the topic: I uploaded after moving the Build-Depends to Depends
- I admit that Build-Depends was by accident and should have been
Depends.  However, this will not solve the original problem on armel.
The JS package dependencies are required to enable the privacy means[1]
and are not optional but required since it is not only documentation but
also in parts of the code (for instance R/utils-rd2html.R).

So this will shift the armel problem from not buildable to not
installable.  Its a usual trick to add those packages that are in the
list of Depends to the Build-Depends to make sure that a package is only
available on a certain architecture if it will be installable.  This is
more flexible than excluding specific architectures inside the
Architecture field since once the dependency will be available again
there is no need to change the package.

Considering this I'm tempted to add the dependency which does not
exist on armel back to the Build-Depends and ask ftpmaster for removal
of r-cran-knitr for this architecture.

What do you think about this approach?

Kind regards

       Andreas.


[1] https://anonscm.debian.org/cgit/debian-science/packages/r-cran-knitr.git/tree/debian/patches/privacy_breach_fix.patch

-- 
http://fam-tille.de



More information about the debian-science-maintainers mailing list