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
