Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 1 April 2013 at 00:16, Josselin Mouette wrote:
| Le dimanche 31 mars 2013 à 13:35 -0500, Dirk Eddelbuettel a écrit :
| > That is why we have a meta-variable
| >
| > ${R:Depends}
| >
| > in Depends: which gets filled by the R version that compiling the package,
| > currently 3.0.0~20130330-1. And which prevents the migration.
| >
| > The same scheme worked before so I am not convinced we need something more
| > complicated or formal.
|
| I don’t understand how you can say it “worked before”.
| Let’s say you backport a R package from wheezy to squeeze (something we
| tried recently at work). The new R will install without a dependency
| problem, and… all modules will stop working.
|
| > Testing is fine, but within unstable the transition has to be done.
|
| Testing is not fine. The new R version could migrate to testing without
Not if we blocked it. That's what I was trying to suggest.
r-base_3.0.0~20130330 is one day old, there should be a new r-base_3.0.0-1 come
April 3.
And we don't want that in testing. So we should block it. With that, testing
and unstable remain separate as far as R is concerned, and there should be no
further issue.
And no build issue in testing as R 2.15.1 there should be fine. (R 2.15.3
would be better still...)
| the new modules, and testing would be broken. Furthermore, incorrect
| dependencies, including across upgrades between stable versions, are
| generally considered RC.
|
| There are reasons why other interpreters have complex dependency
| schemes: previously to avoid that. Not only your reverse dependencies
| should only depend on the *sufficient* version of R (in this case,
| certainly not the R version used to compile the package, which will lead
| to transition blockades to testing), but they should stop installing
| when the version of R becomes incompatible, and so far nothing
| guarantees that.
|
| Perl has a perlapi-X.Y virtual package to avoid that.
| Python generates python (<< X.Y) dependencies to avoid that.
| There are tons of similar schemes used across the Debian archive to
| avoid such problems, from virtual packages, through autogenerated
| dependencies, to package renames.
|
| It’s OK if you don’t know the best way to do that for your package. This
We did not need for the previous 15 years that R has been part of Debian. If
the release team strongly insists that I ought to add this, I can. It has
not been needed before.
And Perl is an odd example as there are multiple APIs / versions used in
parallel. We don't usually do that with R.
| mailing list is here to ask for advice. But I don’t understand how a
| developer who was clearly not born yesterday can knowingly break so many
| packages, without adding appropriate Breaks, without coordinating with
| the release team, and in the final stage of a freeze.
|
| I’d really appreciate if you could think twice next time, before
| uploading such a big change.
I am truly sorry for any harm and headache caused. I greatly appreciate all
the work the release team does -- I just did not want to create more work for
you. I may well have judged wrong, but I follow past practice with both the
R package (which I have maintained for maybe a dozen years) and previous
transition experience.
Dirk
--
Dirk Eddelbuettel | edd@debian.org | http://dirk.eddelbuettel.com
Reply to: