[R-pkg-team] Bug#1089197: dh-r: Stop generating Depends/Suggests/Recommends from the apt cache

[Andreas Tille]

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