On 6 April 2013 at 17:26, Andreas Tille wrote:
| In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704805#10 Dirk
Eddelbuettel wrote:
|
| > I am not (yet?) sold:
| >
| > -- there is only one "provider" or r-api-*
|
| I can not parse whether this should be a question or a problem.
In more words: We only ever have one (1) package providing an R interpreter.
That package is r-base-core.
Because we only have one package, I do not see why we need an additional
token r-api (or whichever wording we pick).
Let's keep simple things simple.
| > -- we actually do have a "greater than" relation
|
| This is the current implementation and this is not really helpful.
Please demonstrate an actual fault in its design or implementation.
We all have our priorities. To me, quite frankly a bigger issue is that some
debian-{med,science} packages appear to get stale and are not being updated
for years.
| > -- the version numbers already solve this
|
| No, they do not. An API level is something else than a version number.
Version are a (sufficient) superset.
Don't get wrong: I very much welcome your suggestions and involvement.
${R:Depends} was a very good idea which eventually won even me over ;-)
But on this, I am not buying the hype yet. Perl has 'api' virtual packages
because Debian *has* multiple concurrent interpreters. If we are going to
have a discussion then it should be about redesigning R installations on
Debian to permit concurrent R-release and R-devel packages. Which may
require r-api-$N packages -- concurrently.
The current scheme, with its "few" packages, is fine. If I may, I'd simply
suggest more frequent update of the CRAN packages. I update mine typically
within a day to a week after they appear.
Dirk
--
Dirk Eddelbuettel | [email protected] | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
