Catalog hierarchy and iLife

[Chris George]

I’m having a little trouble this morning wrapping my mind around the intended hierarchy of catalogs for use with instaup2date… specifically where the iLife installer would go.

I get that you don’t generally want to alter the “10.6_vanilla” and “iLife11_Updates” catalogs, so that you can just check out a new copy when new updates are released. So where would the iLife installer itself go – which catalog, and under what category? How do you structure the hierarchy so that it processes “10.6_vanilla,” then the iLife installer, then “iLife 11_Updates”?

[Allister Banks]

in the top of the 10.6 vanilla catalog file, add this:
[code]include-file: path/to/iLife11_Updates.catalog[/code]
Then you can totally just add the line for your iLife11 mpkg to the top of the iLife11_updates catalog, but two things of note:

-iLife11 doesn’t play nice like iLife09 did, some people are repackaging, I’m using a catalog that rips the entire distributions worth of packages apart and I comment out the apps I don’t need installed:
[url]http://xrl.us/bkohrd[/url]

-the updates catalog is slightly out of date: Garageband has a new sha1(thanks Apple for not revising the name of the update, it’s this type of thing that makes it difficult to trust your dedication to stable releases) and iPhoto 9.1.3 deprecates/obviates the need for 9.1.2 and 9.1.1.

iPhoto 9.1.3 http://support.apple.com/downloads/DL1379/en_US/iPhoto9.1.3Update.dmg sha1:c2a64e339b74441b6227f0eac664bf867b54420d

[Chris George]

[QUOTE][u]Quote by: Allister[/u][p]in the top of the 10.6 vanilla catalog file, add this:
[code]include-file: path/to/iLife11_Updates.catalog[/code]
Then you can totally just add the line for your iLife11 mpkg to the top of the iLife11_updates catalog, but two things of note:

-iLife11 doesn’t play nice like iLife09 did, some people are repackaging, I’m using a catalog that rips the entire distributions worth of packages apart and I comment out the apps I don’t need installed:
[url]http://xrl.us/bkohrd[/url]

-the updates catalog is slightly out of date: Garageband has a new sha1(thanks Apple for not revising the name of the update, it’s this type of thing that makes it difficult to trust your dedication to stable releases) and iPhoto 9.1.3 deprecates/obviates the need for 9.1.2 and 9.1.1.

iPhoto 9.1.3 http://support.apple.com/downloads/DL1379/en_US/iPhoto9.1.3Update.dmg sha1:c2a64e339b74441b6227f0eac664bf867b54420d[/p][/QUOTE]

Thanks for the update on the updates. 😉

Your description, to me, doesn’t seem to mesh with the description provided in the templates included with instaup2date… which is fine, since it is flexible enough to fit the operator, rather than the operator fitting the program.

I think, instead of modifying the catalogs provided from cvs, I’ll go with the following hierarchy:
[list]
[*]base.catalog
[list]
[*]10.6_vanilla.catalog
[*]iLife11.catalog
[list]
[*]iLife11_Updates.catalog
[/list]
[*]general.catalog
[/list]
[/list]
As far as playing nice – I thought I read that all you needed to do was replace the alias at the root of the image with a relative symlink. True/not true?

[Allister Banks]

Yeah, using a base.catalog is actually the better practice.
I didn’t have any luck with making the symlink real and then everything was hunky-dory, I think the .dist file is pointing at path from root instead of relative location, ymmv.

Allister

[mgb123]

So if I need to create multiple purpose built images, the best way to do so is to create multiple Base.catalog files, and then add or remove specific customizations as I see fit?

I was doing a much less elegant call file 1, which calls file 2, which calls file 3, which calls file 4 sort of setup. Made it cumbersome to decide the order of things.

So what’s the best way to organize the Base catalog? Just call things in order, Vanilla, then common, then (exploded) iLife 11, iLife updates, then regular app load?

Do I need to do any fancy footwork with regards to calling the installer disc in the Base catalog?

[Allister Banks]

Example scenario: I have one department with new MBP’s or iMacs, and however many images I want to build for other dept.’s. I’d make a base catalog for each, one called thunderbolt_base which has an include line for the thunderbolt.catalog to generate a MBP-specific image, and the others ‘calling'(including) the vanilla first instead. I have a generic selection of packages I make a catalog for and include in both bases, just like iLife and its updates get their own catalogs. The heading of the instaup2date catalog section designates what order it gets installed in ‘globally’, so we patch the OS first and leave the settings ’til after the apps we’re modifying are installed. You could even chain everything together by telling instaUp2Date to –process thunderbolt_base others_base etc.
Does that make sense? As long as the discs are located where instaup2date is hoping to find them and there’s enough disk space for the output, it’ll pop out as many images as you want.

Allister

[mgb123]

Totally does make sense- though I’m fuzzy about the way to ensure that I include all the necessary catalog files. Say I have 3 catalogs, and a vanilla, would I just make a base, and then just put in the top

include-file: 10.6_vanilla.catalog
include-file: (Catalog to install 1st after vanilla)
include-file: (Catalog to install 2nd after vanilla)
include-file: (Catalog to install 3nd after vanilla)

Would this be correct?

[Author]

Posts