Hi Gordon, On Fri, Nov 18, 2016 at 02:56:16PM +0100, Gordon Ball wrote: > [only to andreas since I think this is effectively a debian > implementation detail rather than an issue for bioconductor]
Involve Debian Science for wider audience - thus full quoting ... > On 17/11/16 16:14, Andreas Tille wrote: > > Hi Martin, > > > > On Thu, Nov 17, 2016 at 07:04:51AM -0500, Martin Morgan wrote: > >> On 11/17/2016 06:54 AM, Maintainer wrote: > >>> Hi again, > >>> > >>> sorry for nagging again but does anybody have a clue how to use phyloseq > >>> if it requires a not yet released ade4 (>= 1.7.2)? I think it is just a > >>> typo and should be ade4 (>= 1.7-2) but a confirmation of this assumpion > >>> would be very helpful. > >> > >> (a) the Writing R Extensions manual > >> https://cran.r-project.org/doc/manuals/r-release/R-exts.html says > >> > >> The mandatory ‘Version’ field gives the version of the package. This is a > >> sequence of at least two (and usually three) non-negative integers > >> separated > >> by single ‘.’ or ‘-’ characters. The canonical form is as shown in the > >> example [0.5-1], and a version such as ‘0.01’ or ‘0.01.0’ will be handled > >> as > >> if it were ‘0.1-0’. > > > > I fully agree that 1.7.2 and 1.7-2 are perfectly valid version numbers. > > > >> (b) R installs the package, indicating that from it's perspective the > >> dependency is satisfied. > >> > >> From these I think the answer is that it is not technically a typo, and > >> that > >> you would not be making an assumption that the intention was 1.7-2. > > > > May be R is able to resolve the version declared as 1.7.2 inside the > > DESCRIPTION as 1.7-2 installed on the system. However, I consider it > > quite strange that a non-existing version number (while 1.7.2 is valid > > it does not exist anyway) can resolve the dependency relation. The > > quote above does not define any relation between a string containing a > > '-' and a '.'. This fact might make R tolerant against the non-matching > > version string - but Debian is not. > > > > However, in the Debian packaging system is 1.7-2 < 1.7.2. Since we now > > have a new helper system that parses DESCRIPTION files and puts the > > result into the Debian package control information this now creates an > > unresolvable conflict. Your arguing does not leave me any better > > conclusion than to really patch the DESCRIPTION file to get a valid > > version match with ade4 in case you do not consider the non-matching > > string as a bug. > > There is currently no special-case handling for this in dh-r, but I have > previously added version mangling rules in d/watch "by hand" such that > an R package with version x.y-z generates a debian package version x.y.z > (but the DESCRIPTION file still contains x.y-z). > > Policy 5.6.12 does allow "-" in upstream version, so x.y-z-1 is valid, > but I'm inclined to say x.y.z-1 is clearer, and avoids this sort of > ambiguity. I admit when I started packaging CRAN packages I did so as well but in the end I did not consider it a good idea to derive from upstream version string. I ended up with epochs in the version to make sure the version strings containing a '-' sign are considered greater than the one with '.'. Since I think upstream should not simply use a non-existing version string which is IMHO a bug we should probably always stick to the official version string and just fix those bugs. > See, eg uuid/r-cran-uuid (R version 0.1-2, debian version 0.1.2-6). I do not think that we should do this. > This approach could be added to dh-r (ie, mangle the version string from > DESCRIPTION and add dversionmangle/uversionmangle rules to d/watch) - > worthwhile? No, I think we should not support this. Kind regards Andreas. -- http://fam-tille.de
