Hi Paul,
Am Thu, Nov 02, 2023 at 07:23:55PM +0100 schrieb Paul Gevers:
> On 02-11-2023 15:13, Andreas Tille wrote:
> > There is probably one remaining problem. As per file R/zzz.R[2] the
> > function checkMatrixPackageVersion verifies that TMB is running always
> > with the Matrix version it was built against.
>
> Well, I suggested before to just patch that check out. Is it really doing
> any good?
Sorry for my weak memory. I have no idea whether it is really doing any
good.
> If the test suite is remotely well done, it should catch the case
> where rmatrix breaks the package, while enabling running it against any
> version that works.
I might open an Issue about this.
> > Do you see some automatic
> > method to approach this which is better than simply waiting for a CI
> > test to fail (which should happen once a r-cran-matrix package of a new
> > Matrix version is uploaded)?
> Well, if you get the version tightly recorded, the migration software will
> refuse to migrate r-cran-matrix because it would break the version in
> testing. No CI is needed for that. But tight version relations are a pain,
> i.e. they limit apt in finding upgrade orders, so if too many packages do
> that, it might prevent people from upgrading their system.
I did not used a tight Depends (see r-cran-matrix (>= $${rmbversion}) in
[1]) but I think the check you suggested to patch out will fire for new
Matrix versions. Since I understand way to less about the internals I'm
hesitating to patch out something upstream considers necessary without
discussing.
BTW, now we have a new kind of regression[2]
56s Error: (converted from warning) package ‘TMB’ was built under R version
4.3.2
I have no idea how to fix this from my side.
Kind regards
Andreas.
[1]
https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/blob/master/debian/rules#L10-13
[2]
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-tmb/39490349/log.gz
--
http://fam-tille.de
