On 01/05/2013 02:21 PM, Chris Jones wrote:
On 5 Jan 2013, at 10:16pm, Blair Zajac <[email protected]> wrote:
On 01/05/2013 02:12 PM, Chris Jones wrote:
Hi,
On 5 Jan 2013, at 09:53 PM, Ryan Schmidt <[email protected]> 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.
Blair
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
