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

[Blair Zajac]

On 1/8/13 8:51 PM, Blair Zajac wrote:
> On 1/5/13 2:46 PM, Blair Zajac wrote:
>> On 01/05/2013 02:21 PM, Chris Jones wrote:
>>>
>>> On 5 Jan 2013, at 10:16pm, Blair Zajac <blair at orcaware.com> wrote:
>>>
>>>> On 01/05/2013 02:12 PM, Chris Jones wrote:
>>>>> Hi,
>>>>>
>>>>> On 5 Jan 2013, at 09:53 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>>>>>
>>>>>> It seems unfortunate to make the epoch user-visible at all, since a handful
>>>>>> of ports have large unsightly epochs. :/
>>>>>
>>>>> That might be so, but i don't see an alternative. Macports might itself
>>>>> treat the epoch and revision as different things to the package version,
>>>>> which of course they are, but third parties cannot really be expected to
>>>>> understand such nuances. In this case the pkg's created need a single
>>>>> version number I think, so the version constructed for them have to include
>>>>> the epoch and revision numbers, if the system is to properly support changes
>>>>> in them. I don't think this situation is that different to rpm/deb packages
>>>>> on Linux systems, which usually do something very similar, combining the
>>>>> native package version with other versionings.
>>>>>
>>>>> Using _ in the pkg version seems a good idea, as long as they are properly
>>>>> understood, by systems like munki for instance ?
>>>>
>>>> Munki uses the interval version number in the .pkg or .mpkg, it doesn't care
>>>> about the filename.  Given that, I would still rather see consistently named
>>>> filenames.
>>>
>>> Yes, thats what I mean. Would it properly understand a version like 0_3.2.1_0
>>> (and understand that 1_3.2.0_0 was newer) ?
>>
>> 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.

Blair


#!/usr/bin/python

import re
import subprocess

max_integers = 0

content = subprocess.check_output(['port', 'list'])
for line in content.splitlines():
     parts = line.split()
     version = parts[1]

     # Strip leading @.
     version = version.lstrip('@')

     # Remove trailing -\d+ to treat all versions the same.
     version = re.sub('-\d+$', '', version)

     version = re.sub('[^.0-9]+', '.', version)
     version = re.sub('\.+', '.', version)
     version = version.rstrip('.')
     dots = version.split('.')
     max_integers = max(max_integers, len(dots))

print max_integers