On 2 April 2014 at 17:31, Julian Gilbey wrote:
| On Wed, Apr 02, 2014 at 08:53:07AM -0500, Dirk Eddelbuettel wrote:
| > | > I *finally* applied this yesterday. Thanks so much for prodding me to
do this.
| > |
| > | Great, thanks!
| >
| > Thank you. A big bunch. I used to be more responsive as a maintainer but I
| > seen to more swamped these days... So thanks for your patience.
|
| It's a pleasure! I fully understand what it is to be swamped ;-)
|
| > | Now all that's left to do is the Provides: r-api-3.0 stuff ;-)
| >
| > I didn't like that discussion very much and still don't think it makes
| > sense. Case in point: my littler package continues to work with R 3.0.* or R
| > 3.1.*. There really is little breakage.
|
| Ah, I think that may be where the confusion lies! r-api-3.0 is
| intended to mean "the API INTRODUCED in version 3.0", not "the API
| CURRENT in version 3.0". (Actually, maybe that should be abi? The
| difference is slight.) Anyway, R 3.1.x is happy to read packages
| built for R 3.0.x and uses the same binary package format.
|
| 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.
| 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.
R Core signals _way ahead_. We "know" when breaking changes will happen. We
can cope. I just this too heavy-handed.
| packages built for earlier versions. So for your little R add-on
| package, should you make your Depends: r-base-core (>= 3.0),
| r-base-core (<= 3.1.99) or perhaps r-base-core (<= 3.2.99) or what?
| You shouldn't just say r-base-core (>= 3.0), because then it will
| break when someone installs r-base-core 4.0.0-1, and aptitude won't
| realise that it needs to install a rebuilt version of the add-on
| package to cope with this. You could say Depends: r-base-core (<< 4),
| but then your package might break when r-base-core 3.5.0-1 is
| installed, because version 3.5.0 happens to break backwards
| compatibility: the upstream R developers don't have a protocol to
| change the major version number whenever they break backwards
| compatibility with packages built with earlier versions.
|
| That's what the r-api proposal is designed to address. R 3.1.* is
| compatible with packages built for R 3.0.*, so it should continue to
| Provides: r-api-3.0. We don't need or want a new r-api-* version
| every time R is upgraded, even when it goes from 3.0 -> 3.1 or
| similar.
Understood.
| In this way, your add-on package could then say "Depends: r-base-core
| (>= 3.0.0-1), r-api-3.0". Then it will happily sit on your system
| until, say, r-base-core 3.5.0-1 is being installed: all r-base-core
| versions up to 3.4.x have Provides: r-api-3.0. At that point, the
| upstream developers decide to change the binary package format, and R
| 3.5.0 will not read packages compiled for earlier versions of R. So
| r-base-core 3.5.0-1 and onwards will Provides: r-api-3.5 ("the API
| introduced in version 3.5"), and then apt will know that your add-on
| package cannot be installed alongside r-base-core 3.5.0-1: your
| package Depends: r-api-3.0 but r-base-core 3.4.3-5, which provided
| that, is being replaced by r-base-core 3.5.0-1, which provides
| r-api-3.5 instead.
|
| 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 :)
| 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.
| > But ... I just built the first r-cran-* package against the new setting and
| > lintian still says:
| >
| > W: r-cran-slam: hardening-no-relro usr/lib/R/site-library/slam/libs/slam.so
| >
| > (Could be a side-effect on building in Debian chroot but running lintian
| > 'outside' under <cough, cough> Ubuntu but I suspect it is legit.)
| >
| > Should we look into fixing the good old r-cran.mk so that hardening is on?
| > (Part of me of course that R packages are probably not the common attack
| > vector though...)
|
| Oh crud. I don't know why that's happening. That's really weird.
| I'm running testing, so I'll have to wait until it migrates or try it
| on my unstable chroot, or install it from sid, or something like
| that.
r-cran.mk doesn't set or export anything. I am a little puzzled
too. Shouldn't that just work? It makes it into R's /etc/R/Makeconf for the
compiler flags.
Ah .. found it. I don't assign ldflags -- doh!
LDFLAGS= \
Will fix.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
