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

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 Eddelbuettel | edd@debian.org | http://dirk.eddelbuettel.com

Reply to: