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

[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]

[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?

[themacdweeb]

alister:

right on.

for a variety of reasons, we’re not using MCX centrally at this point. we will soon i hope and, until then, i get to practice my unix and injecting schtuff into the user template. but i hear you, trust me. as for creating whole plists, I’ve been experimenting with that over the past 24 hours. in essence, i’m tailoring what i have, snapshotting via casper’s composer app (love that thing) and then dropping the pkgs into the instaUp2Date build. we’ll see how that works as i’ve now captured things like: sidebar plists and others.

i’ll check out your idea of echoing to stdout but, again, i’m assuming i’m missing something small in my syntax… usually the case.

d

[themacdweeb]

yes AND that’s all well and fine for images that never change. which isn’t how we work here. yes, your shortcuts are all time-savers to be sure but it skips our issue: if i’m looking to always have a current baseline image, then i’m always going to be downloading the latest and greatest updaters from apple as it’s made available. if i have a local SuS internally, it’d sure be nice to point to that instead of apple’s servers and save the download time for the OS, iLife, security updates, patches, etc.

[themacdweeb]

actually, as combo updaters are now regularly over 1GB in file size, any savings of time would help. just my two cents.

[themacdweeb]

Thanks, gents:

@ larkost: didn’t think it would play well with a hosted SuS but glad to see this verified by some of the work you’ve done.

@ allister: we use casper, we have scripts that point to our hosted SuS, but that wasn’t the point of my post. i’m trying to reduce the amount of time instaDMG takes to run its process and create a baseOS image. i thought that instead of reading a catalog and then downloading each file and update from apple’s servers that we might, instead, point it to our internal SuS to help save download/processing time for instaDMG.

(also been experimenting with reposado, BTW. cewl tewl…)

d

[Author]

Posts