Bug#868558: nmu: multiple r-* packages
Hi Niels et al,
On 26 August 2017 at 07:22, Niels Thykier wrote:
| Dirk Eddelbuettel:
| > [...]
| > On 19 August 2017 at 13:14, Dirk Eddelbuettel wrote:
| > |
| > | Dear release team,
| > |
|
| Hi,
|
| Sorry for the slow up take on our part.
No worries. Releases and Debconfs have a habit of getting in the way :)
So thanks for getting back to me. It will be good to get to this.
|
| > | Gentle poke. We still need this set of NMUs to get R 3.4.1 into testing.
| > |
| > | "Ask me anything" -- What (if anything) is missing? How can I help?
| >
|
| Before I schedule these binNMUs, then I need to understand if partial
| upgrades will be handled correctly. Notably, this case suggests that
| they will not be.
"this case" ? Can you detail? I am not following.
| If someone was to upgrade R and (for the sake of the example) a rebuilt
| r-cran-logspline, what will ensure that the rest of the affected R
| packages are upgraded (or removed)?
They do not need to as this is NOT an API breakage. See it rather as a
garden-variety bug on the part of R Core. "They" have an issue affecting a
subset of dyn.loaded modules (not all, just those using .C() or .Fortran())
where the now-required changes messes things up.
This only affects isolotated calls within a package, not across-package
relationships.
It does not require 'dependent rebuilds' as it does not affect other
packages.
In sum, I am _really fairly certain_ that we "just" need these 40+ NMUs.
| In a regular ABI bump, everything is rebuilt against a new ABI package
| and the old one is (eventually) removed. As I understand it, we are not
| doing that here (nor a variant of it), so you would have to use "Breaks"
| to ensure this property holds. But while Breaks on binNMU versions is
| possible, it can give you headaches if binNMU versions are not in sync
| between architectures.
We _will_ need an ABI nump next spring when real internals change with R as
they gave two or three times in the 15+ years I maintained it.
Not this time.
| * Once the above is clarified/resolved, then we can start binNMUs.
Ok.
I can try to demonstrate the "no we don't" argument by trying to see if I can
recreate the initial bug report on spatial in a testing session, then reinstall
just that (R) package locally (directly from R) where it should work. I
should have time for that later. Let me know if it would help.
| > Setting severity to 'serious' which is what the one for r-base is tagged with
| > at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333
| >
|
| Generally, most release.d.o bug does not use severity so it does not
| really affect anything (except it splits our bug ordering up, and
| somebody will probably show up and fix that eventually).
Ok. Feel free to set it back. It was mostly a device to get your attention :)
Best, Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: