make_munki_pkg.sh doesn't work on non-English locales about munki HOT 8 CLOSED

From [email protected] on October 20, 2010 15:52:54

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?

from munki.

From [email protected] on October 20, 2010 23:12:47

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.

from munki.

From [email protected] on October 24, 2010 23:34:08

Fixed in r836 (and cleaned up in r838 ).

Status: Fixed

from munki.

From [email protected] on October 25, 2010 10:20:45

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

from munki.

From [email protected] on October 25, 2010 12:24:26

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.

Status: Started

from munki.

From [email protected] on October 26, 2010 09:40:58

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?

from munki.

From [email protected] on October 26, 2010 09:49:54

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...

from munki.

From [email protected] on October 26, 2010 10:33:27

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 .

Status: Fixed

from munki.