Actually, I just realized a case where it may not help and can possibly do damage.
I regularly do pre-releases leading to R releases. During those I use versions like (see changelog) r-base (2.14.0-1) unstable; urgency=low [...] -- Dirk Eddelbuettel <e...@debian.org> Mon, 31 Oct 2011 05:00:31 -0500 r-base (2.14.0~20111027-1) unstable; urgency=low [...] -- Dirk Eddelbuettel <e...@debian.org> Thu, 27 Oct 2011 12:59:54 -0500 r-base (2.14.0~20111021-1) unstable; urgency=low [...] -- Dirk Eddelbuettel <e...@debian.org> Fri, 21 Oct 2011 14:56:51 -0500 r-base (2.14.0~20111015-1) unstable; urgency=low [...] -- Dirk Eddelbuettel <e...@debian.org> Sun, 16 Oct 2011 00:39:15 -0500 During this two-week period, I fear we may not have "buildability" as these versions would have identified (as R is concerned) as 2.14.0. But I guess as your patch is written, with the "r-base-dev (>= $(shell ...)" we would be ok as we have 2.14.0-1 (first release) >= 2.14.0~201110xx-y (rc release) so there would always have been a 2.14.0 ? I am trying to think of a past transition where this could have created a problem. It may just work... The alternative would be to have the R package create a versioning script (similar to r-cran.mk) that read the version from the Debian changelog (or directly from dpkg, apt, ...) for the Debian R package, rather than querying the R program: edd@max:~$ dpkg -s r-base-dev | grep Version | perl -ne 'print / +([0-9]+\.[0-9]+\.[0-9]+)/' 2.14.1 or even edd@max:~$ dpkg -s r-base-dev | grep Version | perl -ne 'print / +([0-9]+\.[0-9]+\.[0-9]+-[a-z0-9]+\b)/' 2.14.1-1oneiric (on my Ubuntu box where I type this ? We have to be very careful about the regexp. Dirk -- "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too dark to read." -- Groucho Marx -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
