Re: [munki-dev] Apple and munki version numbers w/ MacPorts

[Josh Malone]

I use MacPorts and munki pretty extensively (over 400 pkgs deployed) and only rarely run into version number problems.

IIRC, munki support 5 "levels" of the version number so you should be good there. I would recommend using only digits where possible, but I know some pkgs (like jpeg) have a letter in their version and all seems to be well for me. YMMV but it hasn't caused me any problems. :)

What *has* caused me problems are packages with dashes in the *name* of the package - like "fftw-3" and such. Munki uses the dash as a name-version separator so my script that imports all my MacPorts pkgs replaces those dashes with underscores in the Munki package name. The actual OS pkg still retains the name of "fftw-3" but munki calls it "fftw_3":

Output from "pkgutil --pkgs":

  org.macports.faad2
  org.macports.ffmpeg
  org.macports.fftw-3-single
  org.macports.fftw-3
  org.macports.fftw-single
  org.macports.fftw

Finally, I think that updates to components of mpkgs should work just fine -- the OS regards the "sub-package" as a package all on its own (see output of pkgutil --pkgs). Munki does not keep track of what it has installed or how -- all packages are created equal.

-Josh

On Fri, Jan 4, 2013 at 2:53 AM, Blair Zajac <bl...@orcaware.com> wrote:

I'm using MacPorts to build one large metapackage that contains 200+ packages.  This is to distribute an internal application that needs many packages not provided by OS X.

My question relates to how MacPorts should create version numbers for PackageMaker and how many digits does Apple's installer and Munki uses.

For example, I'm packaging Qt 4.8.4 and MacPorts provides an epoch number to support reverting to an older release (say 4.8.4 has a bug and we need to back down to 4.8.3) and a revision number to support changes to the build recipe.  So a full version number could be 0_4.8.4_2, with epoch == 0 and revision == 2, where _ separates MacPorts' numbers from the upstream version number.  If I convert this to 0.4.8.4.2 and MacPorts updates the build recipe to 0.4.8.4.3, will Munki and/or Apple's installer see this as an upgrade of the package?

Do the version parsing tools support any number of .'s?  Must I only use digits?  If an upstream package has a character in the version number, should I strip it?

Finally, since I'm thinking about it, if the large metapackage contains Qt 0.4.8.4.2 and then I build 0.4.8.4.3 as a package and drop that in Munki, will Munki see it as an upgrade to a package contained in the large metapackage?

Thanks,
Blair

[Gregory Neagle]

On Jan 3, 2013, at 11:53 PM, Blair Zajac <bl...@orcaware.com> wrote:

> I'm using MacPorts to build one large metapackage that contains 200+ packages. This is to distribute an internal application that needs many packages not provided by OS X.
>
> My question relates to how MacPorts should create version numbers for PackageMaker and how many digits does Apple's installer and Munki uses.
>
> For example, I'm packaging Qt 4.8.4 and MacPorts provides an epoch number to support reverting to an older release (say 4.8.4 has a bug and we need to back down to 4.8.3) and a revision number to support changes to the build recipe. So a full version number could be 0_4.8.4_2, with epoch == 0 and revision == 2, where _ separates MacPorts' numbers from the upstream version number. If I convert this to 0.4.8.4.2 and MacPorts updates the build recipe to 0.4.8.4.3, will Munki and/or Apple's installer see this as an upgrade of the package?

If the version number of the package is higher, yes, it will be seen as an update/upgrade.

>
> Do the version parsing tools support any number of .'s?

Munki's do. Not sure about Apple's. I've never seen more than five "components" in Apple package version numbers that I can recall.

> Must I only use digits?

For best results, yes. Version "numbers" containing non-digits may not compare in the way you might expect.

> If an upstream package has a character in the version number, should I strip it?

That is up to you and might depend on other factors.

>
> Finally, since I'm thinking about it, if the large metapackage contains Qt 0.4.8.4.2 and then I build 0.4.8.4.3 as a package and drop that in Munki, will Munki see it as an upgrade to a package contained in the large metapackage?

Are both your large metapackage and Qt listed as managed_installs? If Qt is not a managed_install or a dependency of your large metapackage (that is, your large metapackage "requires" Qt) then Munki doesn't know it should do anything with a new version of Qt you've uploaded.

>
> Thanks,
> Blair
>

[Blair Zajac]

On Friday, January 4, 2013 7:18:09 AM UTC-8, JoshMalone wrote:

I use MacPorts and munki pretty extensively (over 400 pkgs deployed) and only rarely run into version number problems.

Thanks, that's good to hear.  I'm a MacPorts committer and made some changes to MacPorts' pkg and mpkg commands that will be in the next release:

1. Generated .pkg and .mpkg files epoch and revision in them, surrounding the port version number, e.g. python27 will be 0_ 2.7.3_1.
2. The package number now includes the epoch and the revision number.  I also replace any non-period and non-digit characters with a period.  So the scala2.10 package when it was for Scala 2.10.0-RC3 would become 0.2.10.0.3.0:
1. 0 => epoch of 0
2. 2 => 2 from 2.10.0-RC3
3. 10 => 10 from 2.10.0-RC3
4. 0 => 0 from 2.10.0-RC3
5. 3 => 3 from RC3
6. 0 => the port revision number

IIRC, munki support 5 "levels" of the version number so you should be good there. I would recommend using only digits where possible, but I know some pkgs (like jpeg) have a letter in their version and all seems to be well for me. YMMV but it hasn't caused me any problems. :)

What *has* caused me problems are packages with dashes in the *name* of the package - like "fftw-3" and such. Munki uses the dash as a name-version separator so my script that imports all my MacPorts pkgs replaces those dashes with underscores in the Munki package name. The actual OS pkg still retains the name of "fftw-3" but munki calls it "fftw_3":

I'll do this also for my import script.

Regards,
Blair
 

[Blair Zajac]

Thanks for this hint, I'm new to Munki and I got the metapackage and an updated package to dist successfully to my Mac.

Regards,
Blair
 

>
> Thanks,
> Blair
>

[JoshMalone]

On Saturday, January 5, 2013 1:47:04 AM UTC-5, Blair Zajac wrote:

Thanks, that's good to hear.  I'm a MacPorts committer and made some changes to MacPorts' pkg and mpkg commands that will be in the next release:

1. Generated .pkg and .mpkg files epoch and revision in them, surrounding the port version number, e.g. python27 will be 0_ 2.7.3_1.
2. The package number now includes the epoch and the revision number.  I also replace any non-period and non-digit characters with a period.  So the scala2.10 package when it was for Scala 2.10.0-RC3 would become 0.2.10.0.3.0:
1. 0 => epoch of 0
2. 2 => 2 from 2.10.0-RC3
3. 10 => 10 from 2.10.0-RC3
4. 0 => 0 from 2.10.0-RC3
5. 3 => 3 from RC3
6. 0 => the port revision number

Is there any way I can turn off this behaviour? I need to push updates to clients that already have versions installed without the epoch prefix.

-Josh

[Blair Zajac]

On 11/05/2013 09:47 AM, JoshMalone wrote:
>
>
> On Saturday, January 5, 2013 1:47:04 AM UTC-5, Blair Zajac wrote:
>
>
>
> Thanks, that's good to hear. I'm a MacPorts committer and made some
> changes to MacPorts' pkg and mpkg commands that will be in the next
> release:
>

> 1. Generated .pkg and .mpkg files epoch and revision in them,

> surrounding the port version number, e.g. python27 will be 0_
> 2.7.3_1.

> 2. The package number now includes the epoch and the revision

> number. I also replace any non-period and non-digit characters
> with a period. So the scala2.10 package when it was for Scala
> 2.10.0-RC3 would become 0.2.10.0.3.0:

> 1. 0 => epoch of 0
> 2. 2 => 2 from 2.10.0-RC3
> 3. 10 => 10 from 2.10.0-RC3
> 4. 0 => 0 from 2.10.0-RC3
> 5. 3 => 3 from RC3
> 6. 0 => the port revision number

>
>
> Is there any way I can turn off this behaviour? I need to push updates
> to clients that already have versions installed without the epoch prefix.

No, there isn't. Two choices, one is to back down to an older MacPorts
version or look through svn history here and apply reverse patches that
are authored by me: bl...@macports.org

https://svn.macports.org/repository/macports/trunk/base/src/package1.0/

Probably, the long term safer bet is to do the later.

Blair

[Josh Malone]

Bummer.

Well - I went ahead and modified portpkg.tcl to take out the epoch
number from the version strings. Seems to be working. I'll take the
discussion over to macports lists.

Thanks,

-Josh

> --
> You received this message because you are subscribed to the Google Groups
> "munki-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to munki-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.