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).
The problem for package maintainers is that no-one knows in advance
when the upstream R developers are going to break compatibility with
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.
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.
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?
> 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.
Julian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
