[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:59:45AM +0200, Andreas Tille wrote:
> > 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
> 
> Yes, I understand that a versioned depends of dplyr would avoid trying
> to pick the version from testing.  But this should be dealt by a
> transition rather than picking a "random" (??? - that is my question
> about) package from the dependencies and make it versioned.

Yes, but at the moment AFAICS, there's no transition going on for R from
release team side, or am I missing something? I don't see any such
request here, at least

	https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-release@lists.debian.org

Why do you think it will fix itself?

OR, are you treating "testing migration" as "transition", and using them
interchangeably? (Please use words accurately in this context if that is
the case, it can quickly lead to confusions like these).

Yes, it can be fixed by a testing migration of both, r-base *and* dplyr, but
it will simply not migrate to testing since it'd build against a version of dplyr in
testing. You need to make it versioned to pickup the one from unstable
OR ask the release team to trigger debci with deps from unstable, which
they only do on a case-by-case basis.

> > | 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 confirm that this would help the Debian migration case.  However, I
> was trying to backup this case by any R codebase reason.

I think that's currently not a possibility w/o a proper release
transition / release-team coordinated transition. You can't get around
avoiding this work here, unfortunately.

> If we fiddle around with versioned Depends to work around a transition issue this
> will end up in a lot of manual work,

I did quite a lot of manual work for past R migrations. I
remember handling such migration issues for past R migration to testing.
You might not have noticed it because I did the uploads quickly after
the said failures.

> I also fail to see your point in the importance of backports.

If we happen to backport R, dplyr (built against backported R) and epi
someday, a versioned depends like this will help to get the
autopkgtests passing and epi working in backports.

But yes, this has got nothing to do with r-cran-epi or r-cran-dplyr specific "code changes"
as such.

> Which is the case in unstable, isn't it?  Both are built against the new
> graphics API and I fail to see in how far dplyr and epi are in any way
> special compared for those lots of other R packages with bug reports.

They need to be re-compiled versions of one-another.

> Its not about ignoring your suggestion.  I simply want to understand it
> to apply it properly.  As far as I can see those versioned Depends do
> not have any internal reason when considering the R code. 

I agree, it is not about the code changes, but rather about the API
changes at a toolchain level. I think the BRs are helpful in this
particular case of r-base transition to 4.3.1 (but mayn't be in general).

> They would be helpful to solve the trouble we are in now due a not properly announced
> transition.

I think we are trying to speak of the same things in different ways, and
we seem to be in agreement.

To answer your question - I don't think there's anyway to avoid trouble
with un-announced r-base uploads. Like every other major
package (like for instance htslib in debian-med). A proper binNMU
transition coordinated with the release team is the way to go.
Randomly bumping a whole compiler will inevitably lead to a situation we
are currently in.

> So we need to decide what to do.  I'm in favour of making either a full
> transition or we try to implement the r-graphics-api-* Suggestion[1].  I
> personally prefer the later one since its more clean and affects less
> packages.

Absolutely, I agree that[1] is the way to go.

> [1] https://lists.debian.org/debian-r/2023/06/msg00017.html

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/e409d085/attachment.sig>