Dirk Eddelbuettel: > > 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. > No; it is true. It is a breakage. > 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. > No; because the package relationships do not ensure partial upgrade safety, britney can (and will) migrate the packages to testing out of order. Concretely, since all rdeps have recently been rebuilt, they will have to wait 5 days while r-base will migrate immediately. In this scenario, the users will "break" their systems even with a regular "apt-get dist-upgrade" while applying every upgrade available to them. And no, this is not just a question of "waiting 5 days". Even then Britney will not enforce that they migrate at the same time (and how could she, when no one informed her of the proper relations) > [...] > > I understand the release loves BREAKS but it does not solve a problem that > needs solving here. I am sorry you feel that way and that you refuse to acknowledge this as a problem. However, it is a real issue and it will cause pain and grief for users and the release team. To be perfectly, honest, I would prefer if you did a proper ABI-like transition over the Breaks. At this scale, Breaks seems too fragile and too likely for people to get wrong. > 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. > I respectfully decline. I have instated this block as a release manager (a delegated position), who is responsible for the contents for the testing suite including the migration rules. If you want this block lifted, please implement a proper ABI-like transition OR the Breaks. You have my preference, but I will accept either solution. (Technically, I will also accept a revert of r-base, but I doubt this is interesting to you) If you feel this is unjust, you are welcome to appeal this according to the rules of the constitution. If memory serves, your only option is to propose a GR (but I could be wrong; please consult the Debian secretary). > | > | 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 > It may be apples-oranges to you; for me it is not. Your proposed migration *will* break things because no tooling can sanely ensure that the users will receive a self-contained consistent selection of r-packages. Thanks, ~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature