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

Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)

On Fri, Apr 05, 2013 at 09:04:41PM -0500, Dirk Eddelbuettel wrote:
> First off, let me apologize. I clearly did this the wrong way and should have
> contacted -release and -devel beforehand. My bad -- I'm sorry for extra work
> this created for the release managers and maintainer, particularly at this
> time.
> R 3.0.0 was released on April 3 as scheduled. As usual, I built a package the
> morning of, and all build daemons are current. (There was also an unrelated
> bug which is why were at 3.0.0-2.)  The release team kindly put a block on
> it, so it will make it into testing.  Good.
> [...]
> So 127 packages are already taken care of.  On the other hand, we still have
> ~50 packages needing work:
> [...]
> R> print(todo[ order(todo[,2]), ], row.names=FALSE)
>                        pkg                                              maint
>                 r-cran-erm                                     jdg@debian.org
>        r-cran-raschsampler                                     jdg@debian.org

I uploaded these to unstable on Friday lunchtime, and they were
accepted into unstable on Friday afternoon; I'm unclear why they are
still in your list?  Did I do something wrong?

Oh yes, I clearly did.  Even though I built it in a chroot with
r-base-dev 3.0.0-2 installed, I forgot to update the Depends lines in
the control files.

So something doesn't make sense somewhere: if my package doesn't care
which version of R it's building against, but R itself cares, then
surely there should be some way of querying r-base-dev during the
build process to enquire which version is required?  It is almost
certainly too late to do anything about this for wheezy, but it would
be good to think about doing something for wheezy+1.  Ideally, this
would be by creating a misc substvar so that instead of having to
specify the version of r-base-core in the Depends: field, it could be
specified just as ${misc:Depends} and then filled in automatically.

Anyway, I'm rebuilding them now with the dependencies updated to


Reply to: