Odd Package Installation Failure

[themacdweeb]

Hey Kids,

I’m seeing a curious thing in the results of my instaUp2Date builds: some packages always work, others never do. In my case, two never work. What’s odd is that both of these PKG’s install images files into the root library folder: in our case, a set of custom desktop and user account images that we bury at…

/Library/Desktop Pictures/Getty – fails to install!
/Library/User Pictures/Getty – fails to install!

Two two PKG’s that install to these location won’t install. No data shows up in these location. And this, despite other PKG’s intended for the same directory working perfectly:

/Library/Fonts/Getty – works!
/Library/Getty/Image Notes – works!

All PKG’s are created with Composer. Additionally, we see no errors in the install or debug logs. I’ve re-packaged but no success thus far. Out of the 15-20 PKG’s we’re laying down, only these two listed above won’t install. I’ve looked at all properties of the directories I’m about to package via Terminal in order to ensure that I’m not laying down files with improper ownership or permissions but…. it all looks good. It works on the host machine, it works to create the PKG’s, it works according to the logs when I lay them down and then…. there’s nothing there.

Any advice would help, puh-lease!

Cheers (and beers),

David Koff
SysAdmin
The J. Paul Getty Trust

[larkost]

Two possible guesses:

1) That you are using the same package id for multiple packages. If the have the same value, then the installer will treat the second one to install as an upgrade of the first. If there are files in the first that are not in the second, it will helpfully delete those for you. While this is the right thing for the installer to do, it can be a bit surprising if you are not paying attention.

2) The relocatable bit gets set on a package. This was added by Apple some time ago in response to people moving applications out of /Applications, and then objecting when updaters would then fail to update the package in the new location and leave a broken shell in /Applications. Unfortunately the logic used to find where people have moved things can come up with very unexpected results. This often comes up when people are testing their packages on the same computer they created them on (a natural thing to do) and the package instead updates the copy in the folders they used to make the installer.

The second is not as likely in your case, since it requires a bundle with a bundle id (Applications, Frameworks, etc…), but it is a good thing to keep in mind.

[themacdweeb]

[quote]1) That you are using the same package id for multiple packages. If the have the same value, then the installer will treat the second one to install as an upgrade of the first. If there are files in the first that are not in the second, it will helpfully delete those for you. While this is the right thing for the installer to do, it can be a bit surprising if you are not paying attention.[/quote]

forgive a n00b but how would i learn what the package ID is for each of the objects i drop into the instaUp2Date build folder?

[foilpan]

check like so. composer may show you this in the editing pane somewhere, but i forget where.

defaults read /path/to/app.pkg/Contents/Info CFBundleIdentifier

[themacdweeb]

i’ll be damned.

indeed, some of my bundle identifiers were identical. never even knew about this, never even HEARD about this. hell, it just goes to show that even after 5 years of making packages with various tools that i still have more to learn. nothing wrong with that, of course. but this totally explains why, when i changed some of my package names, that the order of which files got installed shifted: it was due to which pkg with the same bundle ID got laid down first.

wow.

so i’ve gone in with textwranger and changed that entry of that pilist key and we’ll see what happens. don’t know if i also have to change permissions or resnapshot from scratch after making these manual changes, but i’ll find out.

thanks to larkhost and foilplan. couldn’ta done without ya, folks.

d

[themacdweeb]

well, some success and some setback…

after checking and – in some cases – editing a PKG’s CFBundleIdentifier in order to avoid any two packages having the same ID, i re-ran instaUp2Date, recreated my vanilla image and some of my packages were not injected into the proper locations. i used textwrangler to edit the CFBundleIdentifier key in each of the affected plists. i don’t know if editing this way makes a difference or not but i’m going to try re-packaging each item that’s not working and see if that makes a difference.

oy.

feels like i’ve come a very long way, gotten nearly 95% of things to work and then…. one last hurdle.

[Author]

Posts