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
Attachment:
signature.asc
Description: PGP signature