Re: clarification re: Mac OS X standard directories inside a component’s hierarchy
Re: clarification re: Mac OS X standard directories inside a component’s hierarchy
- Subject: Re: clarification re: Mac OS X standard directories inside a component’s hierarchy
- From: Iceberg-Dev <email@hidden>
- Date: Fri, 28 Aug 2009 00:38:59 +0200
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.
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?
o There is a minor bug related to custom folder icons when you set
the default location to be a standard directory instead of /.
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.
What you should not do (if you can) is to allow overwriting of the
permissions of these standard directories.
This somehow assumes that you are confident that no other packages
have
messed with them.
right. well, by default the packages i'm creating in Iceberg don't
have "allow overwriting of permissions" on, so i shouldn't have to
worry about that, right?
are you suggesting that it doesn't matter what the
owner/group/permission bits are on any of the enclosing folders if
they already exist? i'd expect for consistency/sanity's sake that one
would want to make the permissions of the enclosing folders the same
as what currently exists [on a reference system].
what if other packages were sloppy and messed with the perms (they had
enclosing folders set to incorrect perms and enabled 'allow
overwriting...')? just hope that the user will eventually run "repair
permissions"?
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.
My $0.02
_______________________________________________
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