On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote:
>
> I like the idea of an api virtual package, as it requires little work from the
> parties involved and solves most of the problem.
I do not only like this but IMHO it is perfectly needed (as for any
other language system we are packaging.
> - /usr/share/R/debian/r-cran.mk, which is used in most R packages and
> produces
> the R:Depends substitution variable, would make packages depend on the
> r-api
> virtual package instead of requiring a version equal or superior to the
> version
> of r-base-core used at build time.
As I said previously in bug #659163 when R:Depends was introduced to regard some
R api based on the expression
R --version | head -n1 | perl -ne 'print / +([0-9]\.[0-9]+\.[0-9])/'
which is independant from a certain package. I do regard the currently
implemented solution as an unneeded restriction. Compared to the
current implementation and the original suggestion in #659163 the r-api
suggestion above is certainly the cleanest and best possible solution
and I'm really in favour of this.
> - Next time R breaks backwards compatibility, Dirk would need to modify the
> Provides: line in debian/control and voilà, the new R core package can not
> be installed on a system without removing or upgrading the R library
> packages
> that were built with the old API.
+1 (or even +2)
> Let's discuss the details on #704805
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.
> -- we actually do have a "greater than" relation
This is the current implementation and this is not really helpful.
> -- the version numbers already solve this
No, they do not. An API level is something else than a version number.
> -- this was needed three times in ten years
There is no point in properly solving a problem only because it does not
happen very frequently. It can perfectly happen that it occures in a
bad timing and a clean solution is always the goal we should approach
inside Debian.
> I think we are overengineering this.
I'm in great favour of the suggestion of Charles and IMHO it is far from
overengineering - just following the usual standard procedure as it is
implemented in all comparable situations in Debian.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130406152615.ga2...@an3as.eu
