GNU Autotools: instale binarios en/bin,/sbin,/usr/bin y/usr/sbin, interacciones con --prefix y DESTDIR

Question

La mayoría de los paquetes que usan autotools son utilidades de nivel de usuario o al menos lo suficientemente alto para ser completamente bajo/usr, o lo suficientemente bajo como para estar completamente por debajo/usr.

Estoy escribiendo un paquete que necesitaría instalar algunos archivos en/bin, algunos en/sbin,/usr/bin y/usr/sbin. Está reemplazando varios binarios existentes que tradicionalmente se ubican en esas ubicaciones.

También necesita instalar un módulo PAM en/lib/security (y obviamente/usr/lib/security no funcionaría).

Ahora el problema es: el prefijo de la configuración predeterminada parece ser/usr/local (puedo controlar ese valor predeterminado en mi configure.ac), y al menos el valor predeterminado de Gentoo Linux es --prefix =/usr (eso es un problema porque anula los valores predeterminados que pongo en mi configure.ac).

Estaba echando un vistazo breve a cómo otros paquetes similares tratan este problema. Aquí están mis resultados:

• bash-4.1 parece instalar en/usr/bin y scripts de distribución construcción mover el binario bash/bin
• Linux-PAM tiene cortes en configure.ac de modo que si el prefijo es "/ usr", va a usar "/ sbin" y "/ lib" para algunos de sus archivos. También establece el prefijo predeterminado en "/ usr". No estoy seguro de qué sucede si el usuario pasa un prefijo diferente.
• shadow-utils establece exec_prefix en "" si el prefijo es "/ usr". Entonces bin_PROGRAMS se refiere a "/ bin", y ubindir se declara para indicar "$ {prefix}/bin" para que ubin_PROGRAMS se refiere a "/ usr/bin"

Mis preguntas son:

• ¿Cuáles son los valores predeterminados de las otras distros para --prefix? ¿Puedo asumir razonablemente que siempre es/usr? Solo estoy preocupado por Linux en este momento, no BSD.
• ¿Cuál de las soluciones anteriores parece la más limpia? ¿Ves algunas mejores soluciones?
• ¿Cuáles son los posibles problemas con las soluciones anteriores? ¿Hay algunas soluciones a esos problemas?
• Estoy bien con la instalación de todo en "/ bin" y la creación de enlaces simbólicos de compatibilidad. ¿Hace el problema más simple?
• ¿Hay algún otro sistema común de construcción que sea aceptable para las utilidades del sistema de bajo nivel que manejarían mejor mis requisitos?

dude en pedir una aclaración de lo que estoy tratando de hacer. Tenga en cuenta que si quiero mantener la compatibilidad con lo que estoy reemplazando, si solía enviar los binarios A y B, uno en/sbin y uno en/usr/bin, creo que solo tengo que poner reemplazos en esos lugares o en menos tienen enlaces simbólicos. Los módulos PAM también tienen una ubicación de instalación fija.

Obviamente voy a votar una respuesta útil. Soy una "respuesta aceptada". Principalmente estoy buscando consejos sobre "qué debería hacer", cuál es la solución más limpia al problema y, si corresponde, una discusión de las opciones y desventajas, pros y contras.(: ¿No es su responsabilidad leer)

Answer 1

Esencialmente, la distinción entre los / y las jerarquías /usr no es y no debe estar en manos del desarrollador original de los paquetes. Como / solo debe contener los archivos necesarios para arrancar y hacer que /usr esté disponible, es una decisión administrativa lo que va al /. Para instalaciones desde el origen, el instalador toma esta decisión y, para las distribuciones, el mantenedor del paquete.

Por razones de suposición, supongamos que alguien está intentando construir un entorno chroot. La distinción entre/usr y/no tiene sentido en el entorno, y no se hará. Todos los prefijos están configurados en /foo/bar/chroot, y cualquier secuencia de comandos de configuración que juegue con $prefix es probable que induzca un comportamiento extraño. Los mismos argumentos se aplican a los scripts, como los ayudantes de empaquetamiento de Debian, que se basan en la semántica usual de $prefix para funcionar.

La solución más limpia es por lo tanto la solución bash-4.1. Básicamente tiene dos opciones claras: divida el paquete en partes críticas para el arranque y no críticas para el arranque, o permita que su secuencia de comandos configure ofrezca un prefijo alternativo para las partes críticas para el arranque, que se establece de manera predeterminada en /, dejando $prefix como /usr .

Answer 2

Existen dos niveles diferentes para esta pregunta, y todas sus preguntas parecen aplicarse al segundo significado (el paquete binario generado por su archivo * .spec, o debian/rules, o un archivo * .pkg). Por lo que respecta a las autotools, NO TE CUIDAS. No debe intentar especificar un prefijo predeterminado que no sea/usr/local en su configure.ac. Especificar dónde se deben instalar las cosas se realiza en los archivos de control de paquetes binarios, y NO en configure.ac. La distribución fuente que utiliza la secuencia de comandos configurada generada automáticamente debe instalarse en/usr/local de manera predeterminada, y cualquier otra cosa es un error de empaquetado.

Si desea tener una distribución de fuente que el usuario pueda usar para instalar fácilmente en una ubicación particular en una plataforma particular, sería aceptable incluir una secuencia de comandos en el archivo tar que lo haga. Por ejemplo, es posible incluir un script de construcción que se ve algo como:

 
#!/bin/sh 

case $1 in 
foo) args='--prefix=/usr --bindir=/bin --sysconfdir=/etc';; 
bar) args='--prefix=/opt';; 
*) args=;; 
esac 
$(dirname $0)/configure $args && 
make && 
make install 

que especifique los argumentos por defecto a configurar para el 'foo' y las plataformas 'Bar', pero realmente suena como sus preguntas son acerca de los archivos de control para paquetes binarios