Re: [devteam-bioc] BioConductor phyloseq defines relation to not yet existing ade4 version

[Andreas Tille <andreas@fam-tille.de>]

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