[R-pkg-team] Bug#1039645: What kind of transition do we want (Was: Bug#1039645: r-cran-epi: autopkgtest failure with r-base (4.3.1-1))

[Andreas Tille]

Am Thu, Jun 29, 2023 at 03:59:59PM +0530 schrieb Nilesh Patra:
> > 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?

I do not think it will fix itself.  Thus I started the discussion here
whether we need a transition or not.  Unfortunately I changed back
subject of this bug since I assumed I might have missed something for
this *specific* package you pointed to.
 
> 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).

I wrote what I meant:  We have a lot of blocked testing migrations since
there is a lack of a bug asking for a transition.  That's why I would suggest
to solve the issue properly by asking release team for a transition (which
should be strictly be filed by the r-base maintainer since this package
has triggered the issue).
 
> 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.

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

I do not want to get around it.  I just want to do it properly.
 
> > 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.

While I highly estimate your work on this for me that's another proof
that we should do it right at some point in time.  Beeing forced to do
manual work while we have a working and established mechanism is a
repeated waste of energy.  IMHO doing things right in the beginning of
the release process will turn out to be helpful for the future.

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

On the other hand if we do a transition to testing both versions will
perfectly fit.  Even more: When backporting to stable both packages
will be freshly build on stable and the ABI issue will not have any
influence any more.  Thus the versioned Depends is also unneeded here.

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

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

I absolutely agree. ;-)
 
> 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.

Good.  So we have the following options:

   1. implement the r-graphics-api-*
      This might be a bit complex since for the moment I do not know
      any means how to detect the packages that need this dependency
      (and how we can implement this into dh-update-R)  So this might
      become technically complex in the first case

   2. Just do a full r-api transition
      This would work but affects more packages than strictly
      necessary.  My gut feeling says we will be able to finish this
      earlier than 1. despite technically not perfect

   3. Blindly ignore the fact that we need a transition and follow
      the hackish workaround by using random versioned Depends as
      suggested by Nilesh for r-cran-epi.

By the was, option 2. has the advantage that we might be able to "sneak
in" the BioC transition which is pending anyway.  This would also not be
a clean but probably efficient solution - options for doing so are
welcome.

If we get any hint how to technically approach 1. (=how to decide
whether a package depends r-graphics-api-*) I'll ask release team for
this option, otherwise for option 2. if I do not hear anything from
r-base maintainer why this would not be a good idea.

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

-- 
http://fam-tille.de