3

I tried using Whitebox's Packages to create an installer for a LaunchDaemon. The daemon calls a shell script, which itself sources a configuration file.

So what I would like is an installer which installs:

  • /Library/LaunchDaemons/my_daemon.plist. (This is not a problem).
  • /usr/local/bin/myscript.sh
  • /usr/local/etc/myscript.conf

I cannot find how to specify the destination path of /usr/local.

Packages doesn't let me edit the destination of these 2 files, and seems to want to install to "./myscript.sh" and "./myscript.conf", even though it did let me define the absolute destination for the .plist file in /Library/LaunchDaemons.

I guess I could write a postinstall script which creates the directories if needed and copies the files there. But isn't there a better/simpler solution which I am overlooking?

In other words, how can I create a .pkg installer which lets me specify absolute directories for some files, and which creates these directories during the install if needed.

Is a postinstall shell script the only solution, or is there a way to have Packages do things automatically, or is there some other package-creation app which would be more practical for this?

Improve this question
3
  • "I cannot find how to specify the destination path of /usr/local." Within the daemon? Additionally, confirm that the /usr/local/ directory exists. Although it's included in your $PATH by default, it doesn't exist by default.
    – njboot
    Jun 21, 2014 at 6:02
  • I hoped the installer would create the directories if needed, but it doesn't even let me specify them.
    – mivk
    Jun 21, 2014 at 8:33
  • @mivk did you get any solutions for this problem?
    – kroky
    Aug 21, 2016 at 12:48

2 Answers 2

Reset to default
2

Rather than using a script to create /usr/local and its subfolders, include them as part of the package's payload. That is, create a prototype "local" folder with "bin" and "etc" subfolders, and your script and conf file in them. Set the permissions correctly (root:admin, 755 for all but the conf file, 644 or maybe 664 for that). Then create an installer package that places that whole folder structure in /usr.

Note that if /usr/local (and some subfolders and files) already exist, the installer will simply merge your package's payload with what already exists (i.e. it does exactly what you want).

Improve this answer
1
  • You mean "places that whole folder structure in /usr/local"? Not in "/bin", right?
    – thoni56
    May 18, 2016 at 10:39
1

/usr/local doesn't exist by default. You have to create it using Terminal in order to use it as a destination path. Open Terminal and enter the following command (triple click it, copy it, and paste it into your prompt). Enter your password when prompted:

sudo mkdir /usr/local/{,bin,etc}; chmod -R 775 /usr/local/; chown -R root:admin /usr/local; exit

The first part makes the directory and sub-folders, the second modifies its permissions, and the third modifies ownership.

Improve this answer
5
  • Thanks, but I know all this, and could write a shell script which does everything needed. I edited the question to make it more clear.
    – mivk
    Jun 21, 2014 at 12:54
  • 1
    triple click it, copy it <-- I did not know that. +1
    – Rob
    Jun 21, 2014 at 12:56
  • 2
    The above can be shortened quite a bit by using sudo mkdir -m 775 -p /usr/local/{,bin,etc} and accepting that root:wheel is more or less the same as root:admin.
    – Asmus
    Jun 21, 2014 at 15:34
  • @Asmus I like the shortening, much tidier, but I don't understand how root:wheel is equivalent to root:admin in practice.
    – njboot
    Jun 22, 2014 at 0:03
  • 1
    @njboot Well, as long as you're an admin user (which in a "normal" setup is equivalent to being able to sudo) you can do whatever you want with these folders anyway; for non-admin users ("staff") both :wheel and :admin are restrictive in the same way. The major difference is whether an admin user has to type their password or not. If a file is not meant to be touched "by accident" using root:wheel is the safer way, that's also why most Apple-provided apps are setup as root:wheel. If it's only meant to be touched by admins, you could also be the owner yourself.
    – Asmus
    Jun 22, 2014 at 14:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .