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

[Joshua Root]

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).

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."

- Josh