Hi Philip, thank you for the detailed information. I simply replaced all occurences of apt-cache (which admittedly does *not* affect the creation of a resulting binary package).
Your hint to[1] in your re-opening mail was helpful. Am Thu, Dec 19, 2024 at 11:31:14AM +0100 schrieb Philip Rinn: > [please keep me and the bug in cc] > > Hi, > > during the effort to reproduce Debian binary packages distributed via > deb.debian.org (see https://reproduce.debian.net) it turned out that > many/most/all R package couldn't be reproduced as some > Depends/Suggests/Recommends where missing. > > After digging it bit - the missing build-dependency on apt was unfortunately > just a red herring - it turns out, the problem is that > check_real_version_of_package() in dh/R.pm[1] uses 'grep-aptavail' and thus > the result depends on the state of the apt cache. > As parse_depends() (in dh/R.pm) calls check_real_version_of_package() to > build Depends/Suggests/Recommend they depend on the status of the apt cache > as well. That's correct. > While this seems to be a quite elegant solution to the problem of mapping R > package names to Debian package names, it turns out to be quite hard to > reproduce the state of the apt cache for a given point in time. > > Jochen reminded me of the solution dh-python chose [2] for that problem and > I do think a (simplified) version of that would work for R packages as well. > > 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 the > dh-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. > As we can't guarantee that, we need the possibility to place a file in > debian/ to amend/override the mapping table dh-r provides. (We could of > course have a helper script creates that file for us.) > > > I'm quite sure, I miss some details here and I do entirely miss the context > of why the current approach was chosen, but I hope, we can start a > discussion on how to make it possible to reproduce R packages going forward. Well, the package names in principle are taken from the metadata contained inside the DESCRIPTION file every R package (they use the same name for their source - so please do not mix up with Debian package). There is also the concept of versioned dependencies. We simply check whether this package / version is available in Debian. I think what would be helpful for me to understand if you could give me some example where the same build results in different packages. I need to admit that I might fail to understand the real consequences of the code and an example would be pretty helpful, thought. Kind regards Andreas. > [1] > https://salsa.debian.org/r-pkg-team/dh-r/-/blob/5d6dc04ba4f1f1b5db4bfaecc0e00893e46e5c72/dh/R.pm#L147-L170 > > [2] > https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/pydist/README.PyDist -- https://fam-tille.de
