Do you feel this is an issue with GetAvailable, rather than the recipe store?
GetAvailable could make the two lines identical, or merge them, but I'm not sure how that would help the situation. When one compiles a recipe without providing a version number, FindPackage identifies which version to choose by passing all available versions from GetAvailable to GuessLatest. GuessLatest then converts each version component to an integer, effectively sorts them descending (plus checks for prerelease etc), and returns the first one. 2.4.1 and 2.4.01 sort the same, so their original order is preserved and the first one returned from GetAvailable is the first one returned by GuessLatest and FindPackage (assuming there do not exist more recent versions). If both of those recipe versions were stored internally as 2.4.01, they would still sort the same, and it would be equally arbitrary which one FindPackage would choose to provide the url for. On Thu, Apr 22, 2010 at 1:24 PM, Rehan <[email protected]> wrote: > I wonder if it might be a better approach to parse the version for each > recipe of a particular software package and internally pad up to the max > digits found for each decimal position thus making the output correct. > > There are a number of packages of the format a.b.c where c is a number > starting at 1 and rising into the teens. I have seen this a few times. > This might also explain some of failures (which would be false positives > as this is the numbering chosen by upstream which we can do little > about). > > So some software that might start versioning at (for example) 2.4.1 > rising to 2.4.15 would internally be represented as 2.4.01 and 2.4.15. > This would correct the output of GetAvailable. > > > > >> -----Original Message----- >> From: [email protected] > [mailto:gobolinux-devel- >> [email protected]] On Behalf Of Baffo 32 >> Sent: 22 April 2010 16:16 >> To: [email protected] >> Subject: [gobolinux-devel] Patch for Compile/bin/RecipeLint;Issue with >> zero-padded version numbers (Bash 4.1.002) >> >> The recipe store currently contains two conflicting copies of Bash: >> 4.1.002 (from me) and 4.1.2 (from Jonas Karlsson). 4.1.2 works fine, >> but 4.1.002 will not compile due to extraneous patches. >> >> Unfortunately, GetRecipe (and hence Compile) will arbitrarily select >> the broken recipe, if and only if no local recipe is found. It is >> selected because the two are numerically equal and "GetAvailable >> --type=recipe" lists 4.1.002 earlier in its output. >> >> The attached patch adds a check to RecipeLint to ensure a conflict >> like this does not happen again, by rejecting version numbers with >> prefixed zeros. There are currently 208 recipes in the store failing >> this check. >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.730 / Virus Database: 271.1.1/2827 - Release Date: > 04/21/10 >> 19:31:00 > _______________________________________________ > gobolinux-devel mailing list > [email protected] > http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel > _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
