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

Re: R 3.5.0 on April 23 -- new r-api-3.5 and full rebuilds needed



On 23 March 2018 at 14:55, Sébastien Villemot wrote:
| On Wed, Mar 21, 2018 at 02:38:30PM -0400, Chris Lawrence wrote:
| > On Mar 21, Sébastien Villemot wrote:
| > > This proposed scheme does not help for the case where we have to rebuild both
| > > arch:any and arch:all. But it helps when only arch:any need rebuilds (as for
| > > the R 3.4 transition).
| > 
| > Query - is it strictly necessary for us to have a hard dependency on
| > the r-api-x.y version in the arch:all packages? My understanding is
| > these should only have R/S code in them, and the R language is pretty
| > stable, so unless there's a backward-incompatible change in the core
| > language (like fundamental changes in syntax, like getting rid of the
| > legacy "_"-as-assignment was) can't we just rely on a standard minimum
| > dependency on R (>= 3.4.0-1)?
| 
| Even though arch:all packages ship only R code, they still get bytecompiled
| (into .rds file), so there is a potentially an ABI-compatibility issue if that
| format changes.

The argument is a bit of a straw man because R Core signals rather clearly
_when_ such a change occurs. In the twenty years that I have been behind this
package (or helped Doug in the first few of those) we had at most two such
changes: One was when the help system format changed; there may have been
another. In short, this corresponds to MAJOR changes in R. Which are rare.
(Binary change happens more often and can happen with minor releases such as
the upcoming one.)
 
| Still, the ABI tracking for arch:all is very different from that for arch:any,
| so this could justify using two different ABI-like pseudo-packages, as I
| advocated earlier in this thread.

Or just do away with the api-* virtual package for the binary:arch packages?

| > Obviously this wouldn't help with the 3.5 transition but it would
| > dramatically simplify things for future ones if we could go ahead and
| > remove the r-api-x.y dependencies in arch:all packages while doing
| > the 3.5 transition, assuming there's not something I'm missing
| > here. All we'd need to do is adjust the arch:all packages to use a
| > different substvar omitting r-api-x.y, which is a little more work
| > than a manual rebuild but probably could be automated to some extent.
| 
| I agree that *right now* is the ideal timing to implement a change in the ABI
| tracking machinery, since we are going to update all packages if a few weeks.

Which brings us to the change come Monday?  What shall we do?  

We have the pre-releases I made in experimental, but that is just (source)
package r-base.  Come Monday, how do we go about calling for and scheduling a
transition?  Seb, Charles, ... can you lend me a hand as I am a wee bit green
about all this?

Dirk

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


Reply to: