postflight-preflight on snow -leopard
postflight-preflight on snow -leopard
- Subject: postflight-preflight on snow -leopard
- From: Pooja Hemanth <email@hidden>
- Date: Fri, 18 Sep 2009 09:30:25 -0600
- Acceptlanguage: en-US
- Thread-topic: postflight-preflight on snow -leopard
Hi All,
I was trying to run few of the applications and observed in the install log that the postflight scripts don't run on snow leopard.Is any one else experiencing this ? is there a solution ? Am I looking at some wrong log ?
Thanks,
Pooja
-----Original Message-----
From: installer-dev-bounces+adampeck=email@hidden [mailto:installer-dev-bounces+adampeck=email@hidden] On Behalf Of justin blecher
Sent: Friday, September 18, 2009 8:51 AM
To: Iceberg-Dev
Cc: email@hidden
Subject: Re: clarification re: Mac OS X standard directories inside a component's hierarchy
wow, thanks for taking the time to explain all of this -- i really
appreciate it. sorry for it taking me forever to thank you. (this
installer stuff is not my primary job, so i don't get to spend all
that much time on it.)
see below for my comments...
On Thu, Aug 27, 2009 at 6:38 PM, Iceberg-Dev<email@hidden> wrote:
>
> On Aug 27, 2009, at 12:52 AM, justin blecher wrote:
>
>> On Wed, Aug 26, 2009 at 4:28 PM, Iceberg-Dev<email@hidden> wrote:
>>>
>>> On Aug 26, 2009, at 9:45 PM, justin blecher wrote:
>>
>> [...]
>>>>
>>>> * is my assumption/interpretaton -- anytime there are items that
>>>> belong in a "standard directory", a separate package must be made for
>>>> them, targeted to that standard directory -- correct?
>>>>
>>>> * are my evaluations and suggestions for the fixing (hah!) the
>>>> offending packages on the right track? (not like i'm interested in
>>>> fixing them, i'm just trying to grok the concepts for my own
>>>> packages.)
>>>
>>> IMHO, this warning is just plain bullsh*t.
>>
>> ooookay. care to elaborate why you feel that way? :)
>
> Sure:
>
> o This would imply that you have almost to create one package for each
> component you want to install. Obviously if you just need to install one
> .app application in /Applications and you don't need to have it
> distributable through Apple Remote Desktop, you don't need an installer. But
> if you need to install an application, a kernel extension, a launchd script,
> some documentations, etc., you would end up with a lot of components when
> it's not needed.
ok, this is where Apple's docs really confused me. their hypothetical
"Levon.app" project separated the files into separate components and
never really fully explained both sides of the story.
btw, it seems like MS Office 2008 did follow this approach -- they
separated their packages out into dozens of individual packages for
each component, each targeted at a different directory (very
organized, albeit a bit overwhelming). as an aside, the original
12.0.0 installer strangely left no receipts, but the SP1 and SP2
updates left a whole boatload. anyone know under what circumstances
that happens?
> o Not all the standard directories are created by default depending on the
> version of the OS you are using. For instance, /Library/StartupItems was not
> created by a clean install until Mac OS X 10.X X>=3. Other examples can be
> found easily. I have 2 in mind but I can't talk about it before tomorrow
> even though it's the 28th here.
>
> So let's say you need to install something into /Library/THISFOLDER where
> THISFOLDER is a standard directory created in version 2 of the OS but not in
> version 1 and you need to support both 1 and 2. I tend to believe the
> installer will fail to install on version 1 of the OS if you specify the
> default location to be /Library/THISFOLDER and if it works, then where is it
> going to find the correct permissions it needs to apply to this standard
> directory?
excellent point. thanks for elucidating that.
> o There is a minor bug related to custom folder icons when you set the
> default location to be a standard directory instead of /.
hmph. this doesn't concern me immediately. i suppose i'll google it if
it bites me.
> o Apple does not follow this guideline and I'm not referring to the OS. The
> Apple Remote Desktop installation package does not follow this guideline.
> And the guys working on Apple Remote Desktop probably know a few things
> about installation.
>
> When in Rome, do as the Romans do, not as the Visitor Center recommends you
> to do.
interesting. i suppose i'll have to investigate apple's own installers
a bit more closely.
[...]
> The problem is that you can't forecast if the correct permissions are not
> going to change.
>
> For instance:
>
> - /Library/Widgets
>
> Mac OS X 10.4: ./Library/Widgets 40775 0/80
>
> Mac OS X 10.5: ./Library/Widgets 40755 0/0
>
> - /Library/StartupItems
>
> Mac OS X 10.1: root:admin was fine
>
> Mac OS X 10.4: root:wheel was mandatory
>
> Therefore if you are going to overwrite the permissions for a standard
> directory, use the permissions for the most recent release of the OS.
>
> Ideally, you should not have too. Installer.app should be clever enough to
> fix them when you install something inside them.
good point. at the moment, i don't have to worry about supporting
multiple OS versions, as i'm just creating packages for InstaDMG, and
deploying only one OS version. i'll definitely keep this in mind,
though.
thanks again for explaining all of this stuff to a n00b.
-justin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden