On 1/3/13 1:13 AM, Ryan Schmidt wrote:
On Jan 2, 2013, at 16:23, Blair Zajac <[email protected]> wrote:
On my testing on 10.7, the package that is generated from 'port pkg' doesn't
contain any version info, so it looks like Mac OS X treats it as a 1.0 package.
In what way does the Installer use this version info? Or, how are you
determining that OS X considers this to be 1.0?
I built a metapackage (port -v mpkg blairs-meta-package) and ran pkgutil on one
of the ports it installed:
Here's the output for Safari and MacPorts' apr:
$ pkgutil --pkg-info com.apple.pkg.Safari
package-id: com.apple.pkg.Safari
version: 10.7.0.1.1.1306847324
volume: /
location: /
install-time: 1355293532
groups: com.apple.snowleopard-repair-permissions.pkg-group
com.apple.FindSystemFiles.pkg-group
$ pkgutil --pkg-info org.macports.apr
package-id: org.macports.apr
version: 1.0
volume: /
location:
install-time: 1356046967
If we are not indicating the version number in the packages (and from what you
showed of the package creation commands, it doesn't look like we are), and it
can be changed so that we do, then we should change base to do so. It is of
course just one piece of metadata: it would indicate the version, but not the
epoch or revision or license or any of several other useful pieces of
information. But the version is important and if we can indicate it we should.
I agree. Right now when I drop the packages into munki to distribute them to
client Macs, the Macs do not see that there's an updated package.
I do want to get the epoch in there if I can.
BTW, it appears that packages built on older Mac OS X releases do have the
package version number.
Blair
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
