On 01/05/2013 01:32 PM, Rainer Müller wrote:
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.
I argue that consistency is more important here. People are making
packages for a reason, so keeping the epoch number there doesn't need to
be hidden. But I don't feel that strongly about it.
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.
In the work I committed, the .pkg and .mpkg filenames do use _ as a
separator, so it would look like foo-1_3.2.0_0.pkg.
Blair
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
