On 2013-01-05 19:18, Blair Zajac wrote: >> That would cause problems if the epoch for a package is ever increased >> from 0 to 1, since the version number would change unpredictably. >> >> e.g. say you have a package with version 3.2.1 epoch 0, revision 0, so >> if you missed out the epoch when zero, this would give the 'munki' >> version >> >> 3.2.1.0 >> >> say you then increase the epoch to 1 (to downgrade to 3.2.0). the >> version then would be >> >> 1.3.2.0.0 >> >> which is a completely different format to the first, and not obvious >> if it would be seen as newer or not. My guess not. > > Agreed, this would not be seen by Munki as a newer version, but an older > one. Given this and that we would always want to the file version > number with the internal version number (say to make scripts easier to > write), suggests that we keep the epoch there.
I guess munki uses the version number from in the metadata of the pkg and not from the filename, so we could avoid putting epoch 0 in the filename (to keep them short), but still keep the epoch and version in the metadata. Also, what about a different separator for the epoch to avoid confusion? Writing the example above as foo-1_3.2.0_0.pkg would be easier for recognition by humans. Rainer _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
