Re: Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Paul,
On 11 July 2023 at 20:36, Paul Gevers wrote:
| On 11-07-2023 02:43, Dirk Eddelbuettel wrote:
| I'm totally on board for technical excellence, although I think we have
| different things in mind when we say that.
|
| In Debian, with more QA than we ever had before, we're finding a class
| of issues that often went unnoticed years ago. One of these things is
Of course I am not against testing auto-upgrades. I imagine nobody is.
What I am not happy about is that we fell into a hole we would not need to be
in, ideally. Please hear me out on this:
- R has an annual release cycle at the end of April
- During that cycle the 'next' release (in VCS) is referred to as r-devel.
- CRAN checks all packages at all uploads, as well as periodically, against
r-devel.
- When a change is needed because something would break once r-devel becomes
'r-release' they contact the package author and request the change, this
is a hard requirement and non-compliant package are thrown off CRAN. No
- breakage allowed!
- What I showed with maldiquant was that its upstream made the change in
March still well before the R 4.3.0 release requiring it
- So we could have (we had the freeze, more below) had the package which
would have passed both 'r-release' then and 'r-devel then' (which is
'r-release now') and everything would pass. Even under our tests.
That is an ideal I would really like us to move towards with the CRAN
packages in Debian. As CRAN makes it so easy for us to 'always build / build
@HEAD' we really should take the fullest advantage of it.
So I typically roll up my packages the day or week of a CRAN change. (And
maintain 2 x 21k binaries off CRAN in r2u, but that is a different story.)
As it happens, not everybody does, sometimes we have freezes, and other
things happen. Also the number of CRAN packages increases of course and the
net-net of that is that we then have to spend precious manual time picking up
the pieces.
Clearly not ideal, but better than having installation bugs.
| that partial upgrades can leave you in a bad state. So more and more we
| see that packages "have to" add Breaks to tell apt that when you want to
| upgrade package X, you also have to upgrade package Y if you happen to
| have that installed. As package Y can not tell that, package X has to
| add the Breaks on the broken version of Y. As an example, see the list
| of Breaks in libc6 [1]. While partial upgrades aren't officially
Thanks for that. An impressively long list!
| supported, we rely on them nevertheless (even if only for QA (piuparts,
| autopkgtest)), and as a Release Team member I consider that class of
| fixes technical excellence: ensuring as best as we can that the user
| that upgrades a package keeps a working system.
Yes.
| While a rebuild of everything combined with bumping the "api" would
| achieve that, I'm much more in favor of targeted Breaks, like we have
| been discussing here. It's typically more work, but it's more correct.
Fully agreed.
| For the future, with the recent change in dh-r, r-base will be much less
| impacted by this "problem" as the new uploads of reverse dependencies
| can migrate *before* r-base, and hence this class of issues will
I don't think so. The recent change helps with the (approximately a handful
or two CRAN packages) setting the graphics engine check (out of a total of
maybe 1300 CRAN/BioC packages at Debian leaving the many others unaffected).
| disappear once that happens (autopkgtest failures are retried after a
| day). So unless somebody investigates the issues in time, the retry will
We will get the same breakage next time will CRAN assumes (and ensures !!)
everything is current at HEAD, we usually have slippage for various reasons
so in practice I fear ... here we are and remain.
| pass after the migration and the issue will no longer block r-base. I
| can live with that, but I find it a shame nevertheless.
Yep. We should aim to have 'less shame, more technical excellence'.
| So, what do you say: technical excellence and you add the Breaks? Or we
| let this slip in? I prefer the former, I can live with the latter.
I can add the Breaks as a 'best of the worse alternative'. And, I presume, I
can remove the existing four-year breaks? [1]
Cheers, Dirk
[1]
edd@rob:~/deb/r-base(master)$ git blame debian/control | grep -A24 Breaks
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 55) Breaks: r-bioc-graph (<< 1.62.0-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 56) r-cran-bbmle (<< 1.0.20-5~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 57) r-cran-biocmanager (<< 1.30.4+dfsg-2~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 58) r-cran-caret (<< 6.0-84-2~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 59) r-cran-cmprsk (<< 2.2-8-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 60) r-cran-coin (<< 1.3-0-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 61) r-cran-dendextend (<< 1.12.0+dfsg-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 62) r-cran-fields (<< 9.8-3-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 63) r-cran-filehash (<< 2.4-2-2~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 64) r-cran-future (<< 1.14.0+dfsg-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 65) r-cran-genetics (<< 1.3.8.1.2-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 66) r-cran-haplo.stats (<< 1.7.9-4~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 67) r-cran-igraph (<< 1.2.4.1-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 68) r-cran-lava (<< 1.6.5-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 69) r-cran-libcoin (<< 1.0-4-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 70) r-cran-msm (<< 1.6.7-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 71) r-cran-permute (<< 0.9-5-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 72) r-cran-phangorn (<< 2.5.5-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 73) r-cran-popepi (<< 0.4.7-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 74) r-cran-recipes (<< 0.1.6-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 75) r-cran-sp (<< 1:1.3-1-2~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 76) r-cran-spam (<< 2.2-2-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 77) r-cran-units (<< 0.6-3-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 78) r-cran-vegan (<< 2.5-5+dfsg-1~),
52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 79) r-cran-zelig (<< 5.1.6.1-1~)
edd@rob:~/deb/r-base(master)$
--
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: