Re: PackageMaker and custom folder icons
Re: PackageMaker and custom folder icons
- Subject: Re: PackageMaker and custom folder icons
- From: "Erik M. Buck" <email@hidden>
- Date: Tue, 12 Feb 2002 12:18:52 -0600
>
> Use a disk image. The first time a user starts the application, copy or
>
> move the relevant items to /Library/Frameworks, /Library/StartupItems,
>
> /Library/Preferences and /usr/bin. The user will need admin privileges
>
> to
>
> do that anyway, and your application can take care of authenticating the
>
> user and or insisting that the user is an administrator. Finally, don't
>
> copy
>
> things to /Library/StartupItems or /usr/bin without a really good
>
> reason,
>
> and ask the user for confirmation before doing it.
>
>
You're kidding?
No. You seem to be agreeing below. The user must be admin and or
authenticate to copy items into /Library/StartupItems or
/Library/Frameworks. We seem to be in complete agreement.
>
>
If you need to copy files in /Library/StartupItems or
>
/Library/Frameworks, the file ownership may need (read has) to be
>
root:admin. The file permissions needing to be rw(x)rw(x)r-(x) or
>
rw(x)r-(x)r-(x).
>
>
You can only do this in an application by using the Authentication
>
Framework or using a s flagged binary (which is a bad idea).
Yes. Exactly.
>
>
The only utility of Disk Images is to prevent having problems when your
>
final user is decompressing an archive containing file with name longer
>
than the old Mac OS limit. I don't see the difference between having a
>
.dmg file or a .tar.gz file on OS X.
Another utility of Disk Images is simple drag and drop instalation. The
varios installer applications are all broken on OS X in one way or another.
>
>
And last killer point: egg and chicken problem.
>
>
A StartupItem is launched at Startup. If the StartupItem is not
>
launched, the Application doesn't launch. So It's not possible to copy
>
the StartupItem. And so on.
There is no chicken and egg problem because the user has to install the
application at some time. When the user copies the application from a disk
image and double clicks it the first time, the user is authenticated and the
copying takes place. From then on, the application (or another) is started
automatically.
>
>
> There are many UNIX
>
> sites that will not or can not install anything in /usr/bin because it
>
> is
>
> read-only and reserved for system components. That is why
>
> /usr/local/bin
>
> and other directories exist.
>
>
Right.
>
>
> Also consider if ~/Library/Frameworks, and
>
> ~/Library/Preferences are better choices. This approach has the added
>
> advantage that if the installation is damaged (say because of an OS
>
> re-install) then the next time the user runs the application, it can
>
> copy
>
> its files again.
>
>
If you're installing an application on a machine using this, every user
>
will have to install it and overwrite the Application in /Applications.
There is no reason to overwrite an application in /Applications. If
multiple users are sharing an application and or frameworks, there is no
need to copy or install anything when another user wants to use the
applications. There is also /Network/Applications and
/Network/Library/Frameworks which is probably where third party applications
that are shared by multiple users should be installed. The whole point is
that /Library and /Applications are reasonably reserved for components that
come with the operating system. It is not a good idea to clutter them with
user applications.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.