[R-pkg-team] Bug#1039645: r-cran-epi: autopkgtest failure with r-base (4.3.1-1)

[Nilesh Patra]

On Thu, Jun 29, 2023 at 11:00:42AM +0200, Andreas Tille wrote:
> Am Wed, Jun 28, 2023 at 08:18:57PM +0530 schrieb Nilesh Patra:
> > You are correct. A transition is all we need. However, in case of
> > r-cran-epi simply adding a versioned dep on dplyr should do the trick.
> > (epi is not a failure in excuses for dplyr).
> 
> Why exactly do you think that actually dplyr should receive a versioned
> Depends.  It is not specified in DESCRIPTION explicitly and before I
> change d/control to something which is not reproduced by dh-update-R

I don't know where you are looking, but it is very clearly mentioned in
the imports in in the DESCRIPTION file

	https://salsa.debian.org/r-pkg-team/r-cran-epi/-/blob/master/DESCRIPTION#L12

It is also mentioned in the d/control (by you)

	https://salsa.debian.org/r-pkg-team/r-cran-epi/-/blob/master/debian/control#L19

> I would love to understand the background of your suggestion.  Is it just
> because r-cran-dplyr belongs to the affected packages in the graphics
> API that was mentioned by Dirk?

See above. Also, logs like

| 190s Error:  chunk 16
| 190s Error in vectbl_assign(x[[j]], i, recycled_value[[j]]) :
| 190s   DLL requires the use of native symbols
| 190s Execution halted

Point towards an ABI change, and dplyr from testing has been used in the CI

| 216s Selecting previously unselected package r-cran-dplyr.
| 216s Preparing to unpack .../091-r-cran-dplyr_1.0.10-1_amd64.deb ...
| 216s Unpacking r-cran-dplyr (1.0.10-1) ...

In addition to that, r-cran-epi is not mentioned in the excuses for
dplyr

	https://qa.debian.org/excuses.php?package=r-cran-dplyr

So it is apparent that a versioned dep on dplyr is needed.

> > I think this particular bug is sensible because without these versioned
> > depends, epi will fail it's tests (for instance while backporting).
> 
> Why do you think so?

r-cran-epi is an arch:any package that has been built against a new R
version. It needs a version of dplyr that has also been built against
the same R version due to graphics API changes.

> > We
> > can go on closing these BRs on the fly. It would also help you track all
> > the dependencies a bit better.
> 
> But what means "better". 

Well, looking at the bugs can help you track versioned deps better. But
ignore my suggestion if that is not the case here, I won't argue.

> For the moment we strictly trust DESCRIPTION.
> If the DESCRIPTION file would be wrong I'd rather file an upstream bug
> report to add the versioned dependency there.

There's nothing that upstream can do in such a situation. This is a
condition induced due to a transition in debian.

> > PS: Do you need a hand with this transition?
> 
> I'm hoping to fight through r-cran-* as far as no new packages are
> involved.  I've droped some TODOs inside d/changelog of packages that
> need deeper inspection.  I'm currently need to care for r-cran-[t-z]*.
> Packages higher in alphabeth either have issues or had new releases
> since I was there in the last two weeks,

OK. Let me know if you need help.

Best,
Nilesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/r-pkg-team/attachments/20230629/a2075eef/attachment-0001.sig>