On 19.12.24 at 12:34, Philip Rinn wrote:
Hi Andreas,On 19.12.24 at 11:49, Andreas Tille wrote:The main idea is to have a mapping table embedded in dh-r which can be overrode on package level. mapping table would basically be <R package name> <corresponding Debian package name> knitr r-cran-knir ggplot2 r-cran-ggplot2 reshape2 r-cran-reshape2 ...containing a mapping for all packages in Debian unstable at the time of thedh-r upload. This would of course mean that we'd need to keep that list moderately updated in the dh-r package.Well, in principle the package *names* can be calculated more or less - we only need to know whether these are CRAN or BioConductor (or other) packages. However, maintaining dh-r after de facto every new r-* package is a burden I would love to avoid.The more I think about it, I guess we should actually _not_ have a list in dh-r but generate the Depends/Suggests/Recommends at the time of creating the _source_ package. So I'd suggest to have what I called 'package level override' in my first mail (but filling d/control directly). [See the package example below for context of why.]We'd probably need that list in dh-r for a migration period though.
Ah, this is probably nonsense. We could have a mapping in dh-r plus the package specific amends/overrides and still not run into problems like I described in my reply.
So to answer your initial remark: As we have package amends/overrides we don't need a dh-r upload per new r-* package. The important property we need to have is that there is a stable (in the sense of fixed by the version of dh-r and the Debian package version) mapping from R packages to Debian packages.
Best Philip
OpenPGP_signature.asc
Description: OpenPGP digital signature
