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

[Philip Rinn]

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 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.

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.

>> 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.

Sure, I'll try [sorry for the longish introduction but I think it's 
important to get us all on the same page here].

dh-r currently determines Depends/Suggests/Recommends at build time from 
the state of the apt cache.

In a build log, it looks like:

[...]
W: Ignoring specified R dependency: R (>= 2.10)
W: Cannot find a debian package for Suggests:knitr
I: Using r-cran-ggplot2 for Imports:ggplot2
I: Using r-cran-reshape2 for Imports:reshape2
I: BioConductor API version: r-api-bioc-3.19
I: Use r-bioc-qvalue as Debian binary package for variables substitution
[...]

[https://amd64.reproduce.debian.net/api/v0/builds/110379/log]

I'd admit this log is a little special as it has a very sparse apt cache 
containing only the build dependencies of the specific package. (This is 
why it finds corresponding Debian packages for ggplot2, reshape2 but not 
for knitr.)

Looking now at the difference between the package in the Debian archive 
and the one built on reproduce.d.n, we find that the 'Suggests' are missing:

[...]
  Depends: r-api-4.0, r-api-bioc-3.19, r-cran-ggplot2, r-cran-reshape2
-Suggests: r-cran-knitr
  Section: gnu-r
  Priority: optional
[...]

[https://amd64.reproduce.debian.net/api/v0/builds/110379/diffoscope]

So, dh-r drops (at least) missing suggests rather silently at build time.

Imagine now a R package that suggests a R package ('foo') not in Debian 
at the time of uploading to Debian. The result would be that the built 
package would _not_ have a 'Suggests' on r-cran-foo as it doesn't exist 
in Debian a build time.
Fast forwarding to a future Debian where r-cran-foo was uploaded, 
rebuilding the same package (via a binNMU for example) would now lead to 
a different package with 'Suggests: r-cran-foo'.


Hope that helps
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/r-pkg-team/attachments/20241219/eb78fd25/attachment.sig>