Re: Do we really need versioned depends r-base-core including Debian revision
On Fri, Sep 20, 2019 at 10:52:09AM +0200, Andreas Tille wrote:
> Hi,
>
> since I ended up with an R package which I was not (yet) able to install
> on my system I checked the dependencies created by dh-r. The reason
> was that my pbuilder environment includes
> http://incoming.debian.org/debian-buildd
> and so I ended up with a versioned Dependency of a just created
> r-cran-knitr package which had:
>
> Depends: r-base-core (>= 3.6.1-5), r-api-3.5
>
> while
>
> $ apt-cache policy r-base-core
> r-base-core:
> Installiert: 3.6.1-4
> Installationskandidat: 3.6.1-4
> Versionstabelle:
> 3.6.1-5 50
> 50 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages
> *** 3.6.1-4 100
> 50 http://httpredir.debian.org/debian unstable/main amd64 Packages
> 50 http://ftp.debian.org/debian unstable/main amd64 Packages
> 100 /var/lib/dpkg/status
>
> Well, this does not lead to a problem in the long run since r-cran-knitr
> will become available after r-base-core and the issue is void for normal
> users. However, it made me wonder (again) why we really inject that
> strict versioned Build-Depends. I assumed we intended to settle just
> with r-api - and here I'm wondering why r-api remains at 3.6. Shouldn't
> this rather be r-api-3.6?
>
> Moreover I wonder why we need the r-base-core dependency at all if we
> would have the (correct!) r-api version. And if we really need the
> r-base-core dependency whether it wouln't be more sensible to at least
> strip the Debian release and may be we can settle with the first two
> digits (matching the api version). I've digged in dh-R code and found
> this three year old code of Gordon in dh/R.pm:
>
> 22fd80b9 (Gordon Ball 2016-09-04 12:28:57 +0200 149) chomp(my $rbase_version = qx/dpkg-query -W -f='\${Version}' r-base-dev/);
> 22fd80b9 (Gordon Ball 2016-09-04 12:28:57 +0200 150) say "I: Building using R version $rbase_version";
> ^023f5eb (Gordon Ball 2016-09-01 16:28:08 +0200 151)
> 22fd80b9 (Gordon Ball 2016-09-04 12:28:57 +0200 152) chomp(my $rapi_version = qx/dpkg-query -W -f='\${Provides}' r-base-core | grep -o 'r-api[^, ]*'/);
> 22fd80b9 (Gordon Ball 2016-09-04 12:28:57 +0200 153) say "I: R API version: $rapi_version";
> Is this just forgotten code that is just not adapted to the needs we
> have these days?
As initially written, `dh-r` was meant to produce more-or-less identical
output to the existing `r-cran.mk` file provides by `r-base-dev`. I
didn't have a strong reason myself to add this constraint beyond that it
was the existing practice.
Looking at the history of r-cran.mk, that constraint was added in the
packaging for r-base 2.14.2-1 (in Feb 2012). The changelog cites:
* debian/r-cran.mk: Support "R:Depends" expansion in debian/substvars
as requested by Andreas Tille and Charles Plessy (Closes:#659163)
That bugs leads to this thread:
https://lists.debian.org/debian-med/2012/02/msg00074.html
The r-api- constraint was added in r-base 3.2.0-3. Changelog:
* debian/control: The r-base-core package now 'Provides: r-api-3'
which can be used to have r-cran-* depend on a particular API vintage.
(Closes: #704805)
The discussion in that bug seems to suggest that it was intended to
supercede a hard dependency on >= R build version.
Unfortunately, I don't think I know the R core well enough to say
whether the strict r-base dependency can be safely deprecated.
I would _guess_ that in most cases, the `r-api-X` virtual dependency
would be sufficient for pure-R packages, whereas the strict dependency
would make sense for packages containing any compiled extension.
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
Reply to: