make_munki_pkg.sh doesn't work on non-English locales

[GoogleCodeExporter]

I had to make a number of changes for make_munki_pkg.sh to work on my system, 
but I didn't dare to check in the changes for fear of breaking your official 
builds. I also nicked a few features from make_munki_pkg_from_svn.sh and 
changed the script so that it does as much as possible without sudo (all the 
chowns are at the end).

Is there a reason for handling Info.plist and Description.plist manually, after 
packagemaker runs?

Original issue reported on code.google.com by MagerV...@gmail.com on 20 Oct 2010 at 3:17

Attachments:

• make_munki_pkg.patch

[GoogleCodeExporter]

I consider the stuff in code/tools as examples or works-in-progress. They work 
for me, but may require additional work for others to use. I'm happy to accept 
patches, but these tools are pretty low priority for me as far as supporting 
them...

"Is there a reason for handling Info.plist and Description.plist manually, 
after packagemaker runs?"

That was the only way I could figure out how to set the display title and 
description (Description.plist) and to disable bundle relocation (changes to 
Info.plist). Is there a better way?

Original comment by gregnea...@mac.com on 20 Oct 2010 at 10:52

[GoogleCodeExporter]

Alright, I'll check in my changes.

It should be possible to set up all resources before calling packagemaker, but 
since it's a minefield of bugs I wanted to make sure that there wasn't a 
particular reason for doing it the way you do. I'll experiment.

Original comment by MagerV...@gmail.com on 21 Oct 2010 at 6:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Fixed in r836 (and cleaned up in r838).

Original comment by MagerV...@gmail.com on 25 Oct 2010 at 6:34

• Changed state: Fixed

[GoogleCodeExporter]

In general I like the changes (and wonder if you might port the relevant ones 
over to make_munki_pkg_from_svn.sh, or possibly merge the two scripts into 
one)...

I see where you're going with the Applications|Library|usr options, but there's 
a potential minefield there:

Apple's installer uses the pkgid to determine if it needs to remove files when 
installing a newer version of a package.  If a package with a pkgid of 
"com.fake.pkg", version 1.0 installs /fee, /fi, and /fo, and version 2.0 of 
com.fake.pkg installs only /fee and /fi, then /fo will be removed.

Since you are using the same pkgid when you build a package using the 
Applications|Library|usr options, a not-careful or not-informed admin might 
build a package containing only updated tools in /usr, install it, and be 
surprised that the GUI app and launchd stuff was removed (as Apple's installer 
would do since the files in /Applications and /Library would be missing from 
the updated pkg)

Perhaps it would be better to have four possible targets:

everything (default)
Applications
Library
usr

and not allow any combinations of the Applications|Library|usr options.  Then 
also use pkgids that match the targets:

everything:  com.googlecode.munki
Applications: com.googlecode.munki.applications
Library: com.googlecode.munki.library
usr: com.googlecode.munki.usr

This would prevent the issue I've described.  (And 
com.googlecode.munki.applications and com.googlecode.munki.usr would not 
require a restart...)

-Greg

Original comment by gregnea...@mac.com on 25 Oct 2010 at 5:20

[GoogleCodeExporter]

My plan for this was to make munki an mpkg, with apps, lib, and usr inside, but 
I haven't yet figured out how to build mpkgs from the command line. pkgids 
should indeed be made unique for each component, I'll fix that tomorrow.

Merging the two build scripts should be easy too.

Original comment by MagerV...@gmail.com on 25 Oct 2010 at 7:24

• Changed state: Started

[GoogleCodeExporter]

Unique pkgids are submitted as r866. The build script is quickly becoming 
rather ugly - I'll file a separate issue for cleanup and merge with from_svn.sh.

Oh, and can we move munkilib/svnversion so that it isn't updated in the source 
tree, but in the temporary package root in /tmp?

Original comment by MagerV...@gmail.com on 26 Oct 2010 at 4:40

[GoogleCodeExporter]

I had not planned on including munkilib/svnversion in the source tree. But it 
does need to be somewhere inside /usr/local/munki so munkicommon.get_version() 
can read it...

Original comment by gregnea...@mac.com on 26 Oct 2010 at 4:49

[GoogleCodeExporter]

OK, moved it to temporary package root in r868. Marking this as fixed as it 
works on non-English locales, and continuing build script improvements in issue 
41.

Original comment by MagerV...@gmail.com on 26 Oct 2010 at 5:33

• Changed state: Fixed