Where to include port version in 'port pkg' output?

[Blair Zajac]

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