On 01/10/2013 07:28 AM, Joshua Root wrote:
On 2013-1-9 16:12 , Blair Zajac wrote:
On 1/8/13 8:51 PM, Blair Zajac wrote:
On 1/5/13 2:46 PM, Blair Zajac wrote:
A 1_3.2.0_0 style version number won't work with Apple's version
number, which
can only accept digits, so I do the following:
v = "${epoch}.${version}.${revision}
# Convert anything besides a period and number to a period.
v =~ s/[^.0-9]+/./g
# Replace multiple periods with a single period.
v =~ s/\.+/./g
# Trim trailing periods.
v =~ /\.+$//
So for scala2.10's 2.10.0-RC5 release with epoch 0 and revision 2, it
becomes
0.2.10.0.5.2. I don't know if Apple knows how to handle more than 3
integers,
but according to the Munki people, they support this and will install
an updated
version.
I ran into a problem with this system.
$ port -v outdated
The following installed ports are outdated:
aspell 0.60.6_4 < 0.60.6.1_0
The generated internal version numbers are 0.60.6.4.0 and 0.60.6.1.0,
respectively, the later is smaller than the first, so Munki doesn't
see this as
an upgrade.
I'm thinking of changing to a fixed number of digits, adding .0 as
necessary to
reach the number of integers. Since this is an internal version
number, I don't
think this will cause any issues.
According to the below script, the maximum number of integers in a
version number is 6, so I'll use that many.
Does this strategy work in the general case? In particular, are
increases in the original version string guaranteed to produce a higher
pkg version? If I understand your code above correctly, it seems like
1.0a and 1.0b for example would map to the same pkg version (1.0.0.0.0.0).
I've been thinking about that case, such as openssl, and unsure how to
handle it. I could:
1) special case packages like this
2) add a special case for version numbers ending in a single [a-zA-Z],
e.g. 1.0.0b
3) add a special case for version numbers ending in any number of
[a-zA-Z], e.g. 1.0beta
4) convert any [a-zA-Z] to an integer
For 3) and 4) I could treat each character forming a base 52 character
and generating an integer number, so 'beta' would be
52*(52*(52*ord('b') + ord('e')) + ord('t')) + ord('a') == 14058817
this presumes that these longer version strings sort the same way as
versions, which is true for 'alpha' and 'beta'.
It sounds like 2) is a safe solution and if we need to special case
other versions, we can do so.
This is probably why the docs say that "The version of the package is
specific to your package and should not be related to the version of the
applications you install if possible."
Very true :)
Blair
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
