[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#868558: nmu: multiple r-* packages



On 10 September 2017 at 11:20, Emilio Pozuelo Monfort wrote:
| On 09/09/17 13:48, Dirk Eddelbuettel wrote:
| > 
| > On 9 September 2017 at 06:44, Niels Thykier wrote:
| > | Thanks to Sébastien and Andreas for explaining the issue.
| > 
| > Well, was it "explained" ?  They both raised and stressed a hypothetical
| > issue: That "there might be siutations where a partial upgrade breaks"
| > 
| > We don't actually know whether this holds.  This R 3.4.* change was not a
| > full-fledged ABI change.
| > 
| > | That is fine.  Then (to my knowledge) your only option is an "ABI bump".
| > 
| > I still disagree, for this case.
| > 
| > We will likely need one for anticipated internal R changes by R 3.5.0.
| > 
| > |  Until one of these solutions is applied, this bug is "wontfix" and
| > | r-base is blocked from migrating to testing.
| > 
| > I think this is a dissservice to our users.
| 
| The only disservice here is that you refuse to prevent users from getting broken
| systems due to this ABI break. This is particularly surprising given the simple
| fix (adding breaks) and that Sébastien is offering you a patch.

That is just not true.

Someone would have to intentionally try to (and I must use quotes here)
"break" their system by intentionally upgrading only r-base(-core).  If and
when (which will still be unlikely) a call does not get resolved the affected
user would do what every R users knows: "rebuild the package", in this case
upgrade the package too.  Case closed.

It is hair-brained anyway as users typically upgrade in buld: apt-get dist-upgrade.

And to be brutally honest: most users I know compile CRAN packages from CRAN
directly into /usr/local/lib/R so this whole dance about the r-cran-*
packages is somewhat irrelevant, and clearly irrational.

I understand the release loves BREAKS but it does not solve a problem that
needs solving here.  You create a problem by aggrandising what is more or
less a non-issue so that you can then come and tell us BREAKS solves
everything.

Now:

  Excuse for r-base

  Migration status: BLOCKED: Needs an approval (either due to a freeze, the source suite or a manual hint)
  64 days old (needed 5 days)
  Not touching package due to block request by nthykier (please contact debian-release if update is needed)
  Piuparts tested OK - https://piuparts.debian.org/sid/source/r/r-base.html
  Not considered

Dear debian-release:  Please remove this block.

| 
| This is no different from someone breaking a shared library ABI, say libfoo0,
| and then asking for rebuilds of the rdeps, and refusing to bump the SONAME,
| rename the package or add breaks against the non-rebuilt rdeps. That would be
| unacceptable, and so is your case.
| 
| As it was pointed out, look at the recent Python extension ABI break that was
| quickly fixed by adding Breaks and scheduling a bunch of binNMUs.

That is a different issue. I have no time for apples-oranges discussions. We
has no ABI break.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org


Reply to: