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

[Andreas Tille]

Hi Nilesh,

Am Thu, Jun 29, 2023 at 02:52:34PM +0530 schrieb Nilesh Patra:
> > 
> > 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

Sure.  My point was the *versioned* Depends.  It is included without any
version.
 
> > 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

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.
 
> | 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.  If we fiddle
around with versioned Depends to work around a transition issue this
will end up in a lot of manual work,

I also fail to see your point in the importance of backports.
 
> > > 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.

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

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.  They would be
helpful to solve the trouble we are in now due a not properly announced
transition.

Every new upload of those packages of those packages that will be done
with routine-update will remove those versioned depends again (which is
correct IMHO) and we will end up in a manual upgrade mess.
 
> > 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.

Ahhh, OK.  Here we agree.

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.
 
> OK. Let me know if you need help.

Thanks a lot.

Kind regards
    Andreas.


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

-- 
http://fam-tille.de