Hi Scott, Nice email, thanks for putting your thoughts out.
On 6 April 2013 at 13:59, Scott Kitterman wrote: | The problem is the lack of a less than relation. That point is one I can agree with. | 1. Modify the expansion of R:Depends to also include a r-base-core (<< 4.0) | relationship. You'd end up with r-base-core (>= 3.0), r-base-core (<< 4.0). Doesn't work. Package rebuilds are often a) unrelated to rebuilds: this is the third one in 10+ years; one had to do with a change in the internal help system, one enforces a namespace and now we have the current one with large(r) vectors b) do not happen at major number changes -- eg we had the previous one at 2.14.0 so we do not yet know what the values of x and y in (<< x.y) | | 2. Have r-base-core provide a virtual package that gets included in the | expansion of R:Depends. Then you'd end up with r-base-core ((>= 3.0), r-base- | api-3.0. "Maybe". I still want to think through how this could help us with the more important goal of allowing two "versions" of R (in parlance: r-release, now 3.0.0, and r-devel, typically SVN-head, now "3.1.0 (Under development)") The api-tag may actually help with this, as may a version library path. | come into play is if the API is compatibly extended. The current python-sip | in experimental provides Provides: sip-api-8.0, sip-api-8.1. In this way, | newer packages can depend on the newer features while older packages that were | built before sip-api-8.1 was introduced do not need to be rebuilt. But that "incremental feature" model is now how R works, methinks. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
