Le Tue, Apr 09, 2013 at 05:22:22PM +0100, Julian Gilbey a écrit :
> On Sat, Apr 06, 2013 at 12:58:39PM +0900, Charles Plessy wrote:
> > This can be done with the attached patch, that I tested locally.
>
> One tiny fix to the patch is needed (presumably a typo):
>
> > -rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev)
> > +rAPIversion := $(shell dpkg-query -W -f='$${Provides}' r-base-core
> > | grep -o 'r-api.[^,]')
>
> This grep command should be grep -o 'r-api[^,]*' (with a '*' and
> perhaps no '.') so that r-api-3a will be returned as r-api-3a and not
> r-api-3 as needed.
Hi Julian,
thanks for the corrections. I doublechecked the system where I tested my patch
and I can confirm that it contained ${Provides}; sorry for the cut-paste typo.
For the grep command, however, this is definitely a bug in my patch, and
your correction solves it.
I am still in the process of rebuilding my packages because, as Dirk noted,
some of them got outdated since I stopped updating them during the Freeze,
and I take the opportunity for the rebuild to do the update.
Dirk, about the proposed use of a pseudopackage to represent the R API,
here are answers to your comments.
-- there is only one "provider" or r-api-*
-> This is fine: the goal is not to support parallel installation, but to
prevent
co-existence of incompatible package.
-- we actually do have a "greater than" relation
-> Using a pseudopackage provides the equivalent of a "lower than", that ensure
that
ensure that an update will not pull a r-base package that breaks API,
without also
upgrading the installed library packages.
-- the version numbers already solve this
-> At build time, it is not possible to guess what the "lower than" relation
should be,
and therefore the approach with a pseudopackage is more effective.
-- this was needed three times in ten years
-> I will be very happy to benefit from the R API pseudopackage in 2016 :)
Time files
really fast !
Given the infrequency of breakages, we have some time ahead. But in contrary
to the
R:Depends system where we could prove its use in Debian Med/Science before
incorporating
it in r-base-dev, for the pseudopackage approach, I do not see a clean way to
test in
larger scale without having your support.
Cheers,
Charles (not the one of cran2deb, in case some readers are confused :)
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
