Cómo crear un paquete que instala archivos en /usr/local

Intenté usar los paquetes de Whitebox para crear un instalador para LaunchDaemon. El daemon llama a un script de shell, que a su vez genera un archivo de configuración.

Entonces, lo que me gustaría es un instalador que instale:

  • /Librería/LaunchDaemons/my_daemon.plist. (Esto no es un problema).
  • /usr/local/bin/myscript.sh
  • /usr/local/etc/myscript.conf

No encuentro cómo especificar la ruta de destino de /usr/local.

Packages no me permite editar el destino de estos 2 archivos y parece querer instalarlos en "./myscript.sh" y "./myscript.conf", aunque me permitió definir el destino absoluto para el archivo . plist archivo en /Library/LaunchDaemons.

Supongo que podría escribir un script posterior a la instalación que cree los directorios si es necesario y copie los archivos allí. ¿Pero no hay una solución mejor/más simple que estoy pasando por alto?

En otras palabras, ¿cómo puedo crear un instalador .pkg que me permita especificar directorios absolutos para algunos archivos y que cree estos directorios durante la instalación si es necesario?

¿Es un script de shell posterior a la instalación la única solución, o hay alguna manera de que los paquetes hagan las cosas automáticamente, o hay alguna otra aplicación de creación de paquetes que sería más práctica para esto?

"No encuentro cómo especificar la ruta de destino de /usr/local". ¿Dentro del demonio? Además, confirme que existe el directorio /usr/local/. Aunque está incluido en su $PATH de forma predeterminada, no existe de forma predeterminada.
Esperaba que el instalador creara los directorios si fuera necesario, pero ni siquiera me permite especificarlos.
@mivk, ¿obtuviste alguna solución para este problema?

Respuestas (2)

En lugar de utilizar un script para crear /usr/local y sus subcarpetas, inclúyalos como parte de la carga útil del paquete. Es decir, cree un prototipo de carpeta "local" con subcarpetas "bin" y "etc", y su script y archivo conf en ellas. Configure los permisos correctamente (root:admin, 755 para todos menos el archivo conf, 644 o quizás 664 para eso). Luego cree un paquete de instalación que coloque toda la estructura de carpetas en /usr.

Tenga en cuenta que si /usr/local (y algunas subcarpetas y archivos) ya existen, el instalador simplemente fusionará la carga útil de su paquete con lo que ya existe (es decir, hace exactamente lo que desea).

¿Quieres decir "coloca toda esa estructura de carpetas en/usr/local"? No en "/ bin", ¿verdad?

/usr/localno existe por defecto. Tienes que crearlo usando Terminal para usarlo como una ruta de destino. Abra Terminal e ingrese el siguiente comando (haga triple clic en él, cópielo y péguelo en su indicador). Introduzca su contraseña cuando se le solicite:

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

La primera parte crea el directorio y las subcarpetas, la segunda modifica sus permisos y la tercera modifica la propiedad.

Gracias, pero sé todo esto y podría escribir un script de shell que haga todo lo necesario. Edité la pregunta para que quede más clara.
haga triple clic en él, cópielo <-- No lo sabía. +1
Lo anterior se puede acortar un poco usando sudo mkdir -m 775 -p /usr/local/{,bin,etc} y aceptando que root:wheel es más o menos lo mismo que root:admin.
@Asmus Me gusta el acortamiento, mucho más ordenado, pero no entiendo cómo root:wheel es equivalente a root:admin en la práctica.
@njboot Bueno, siempre que sea un usuario administrador (que en una configuración "normal" es equivalente a poder sudo) puede hacer lo que quiera con estas carpetas de todos modos; para los usuarios que no son administradores ("personal"), tanto :wheel como :admin son restrictivos de la misma manera. La principal diferencia es si un usuario administrador debe escribir su contraseña o no. Si un archivo no está destinado a ser tocado "por accidente", usar root:wheel es la forma más segura, también es por eso que la mayoría de las aplicaciones proporcionadas por Apple están configuradas como root:wheel. Si solo está destinado a ser tocado por los administradores, también podría ser el propietario.