Essentiellement, la distinction entre le / et le /usr hiérarchies n'est pas et ne doit pas être entre les mains du responsable en amont des paquets (lire :n'est pas de votre responsabilité). Depuis / ne doit contenir que les fichiers nécessaires au démarrage et à la création de /usr disponible, c'est une décision administrative qui va à / . Pour les installations à partir des sources, cette décision est prise par l'installateur, et pour les distributions, par le mainteneur du paquet.
Pour une justification, supposons que quelqu'un essaie de construire un chroot environnement. La distinction entre /usr et / n'a pas de sens dans l'environnement et ne sera pas faite. Tous les préfixes sont définis sur /foo/bar/chroot , et tout script de configuration jouant avec $prefix est susceptible d'induire un comportement étrange. Les mêmes arguments s'appliquent aux scripts tels que les assistants d'empaquetage Debian, qui s'appuient sur l'habituel $prefix sémantique au travail.
La solution la plus propre est donc le bash-4.1 la solution. Vous avez essentiellement deux options propres :divisez votre package en parties critiques pour le démarrage et non critiques pour le démarrage, ou laissez votre configure Le script offre un préfixe alternatif pour les parties critiques de démarrage, qui est défini par défaut sur / , laissant $prefix comme /usr .
Il y a deux niveaux différents à cette question, et vos questions semblent toutes s'appliquer au deuxième sens (le paquet binaire généré par votre fichier *.spec, ou debian/rules, ou un fichier *.pkg.) En ce qui concerne les autotools sont concernés, vous vous en fichez. Vous ne devez pas tenter de spécifier un préfixe par défaut autre que /usr/local dans votre configure.ac. La spécification de l'endroit où les choses doivent être installées se fait dans les fichiers de contrôle du paquet binaire, et NON dans configure.ac. La distribution source utilisant le script de configuration généré par autoconf doit s'installer dans /usr/local par défaut, et tout le reste est une erreur d'empaquetage.
Si vous souhaitez disposer d'une distribution source que l'utilisateur peut utiliser pour l'installer facilement à un emplacement particulier sur une plate-forme particulière, il serait acceptable d'inclure un script dans l'archive tar qui le fait. Par exemple, vous pouvez inclure un script de construction qui ressemble à :
#!/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
qui spécifierait les arguments par défaut à configurer pour les plates-formes 'foo' et 'bar', mais il semble vraiment que vos questions concernent les fichiers de contrôle pour les packages binaires.