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) ? Chris > > Blair > > _______________________________________________ > macports-dev mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
