[Moving to correct bug report from #726913] On Thu, Apr 03, 2014 at 06:45:57PM -0500, Dirk Eddelbuettel wrote: > | The last major breakage happened when R went from 2.15.x -> 3.0.x; R > | 3.0.0 would not read packages built for R 2.15.x. Before that, it was > | something like 2.9.x -> 2.10.x (though I may be wrong about the > | details). > > Yes. So maybe twice a decade. I don't think that warrants all these > acrobatics.
It's two lines of metadata in r-base. That's it. Nothing more, nothing less. (The original patch is three lines, not two, and means that only one line would need to change when r-base changes.) And they only change twice a decade. It's non-intrusive, maintainers need not do anything different whatsoever and so on. The key point is that only *you*, as maintainer of r-base, are able to do this - no add-on package maintainer can. Some examples of other packages which use this system (some calling it -abi and others -api): apache2-bin, banshee, geany, libhdb9-heimdal, python-numpy, python-sip, erlang-base So it's an accepted Debian approach, it's known to work well and prevents archive breakage. > | The problem for package maintainers is that no-one knows in advance > | when the upstream R developers are going to break compatibility with > > Depends on how closely they follow R. They follow -- that is what maintainers > do. This is true, but the people who are affected are the users. Not every maintainer is very responsive (as we all know only too well). It is far better that a user is told by aptitude/apt-get/... that their installed add-on package is incompatible with the r-base upgrade. It would also mean that the critical r-base transition to testing can only happen when all of the depending add-on packages have been upgraded or removed from testing, making the transition far, far smoother. Yes, it may only happen once every five years, but the pain was significant last time, and this is a very simple way to avoid that next time round. This will also make it easier for you or the then-maintainer of r-base to manage that transition: the archive tools will support you and the FTP team in the process, and not-upgraded packages can easily and automatically be removed from testing - they will have unsatisfied dependencies. > R Core signals _way ahead_. We "know" when breaking changes will happen. We > can cope. I just this too heavy-handed. We didn't cope well last time, and there's no evidence that things will be any different next time. > | [...] > | In this way, no-one has to be prescient, and packages built with the > | new scheme will happily coexist with any r-base-core version that is > | backwards compatible with it. > > We have that right now too :) Yes, but we also have packages happily coexisting with r-base-core versions with which they are INcompatible: a package build with r-base-core 2.15.3-2 is incompatible with r-base-core 3.0.0-1, but dpkg is entirely unaware of this. That's not acceptable. > | So the changes needed are just two: introduce "Provides: r-api-3.0" > | in the r-base-core control file, and add "r-api-3.0" to the echo > | "R:Depends=..." line in r-cran.mk. This will ONLY need changing if > | and when R ceases being backwards compatible with packages built by > | earlier versions. > | > | > | Is that a bit clearer? > > Yes, thank you. It is a nice answer. I just don;t think there is enough of an > issue or question to warrant it. Unfortunately, I believe there is. We could ask TC for their opinion, perhaps? Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
