Im Wesentlichen ist die Unterscheidung zwischen / und die /usr Hierarchien ist und sollte nicht in den Händen der Upstream-Betreuer der Pakete liegen (lesen Sie:Ist nicht Ihre Verantwortung). Seit / sollte nur Dateien enthalten, die zum Booten und Erstellen von /usr erforderlich sind verfügbar, es ist eine Verwaltungsentscheidung, was an / geht . Bei Installationen aus der Quelle wird diese Entscheidung vom Installer und bei Distributionen vom Paketbetreuer getroffen.
Angenommen, jemand versucht, einen chroot zu bauen Umgebung. Die Unterscheidung zwischen /usr und / ist in der Umgebung bedeutungslos und wird nicht gemacht. Alle Präfixe sind auf /foo/bar/chroot gesetzt , und jedes Konfigurationsskript, das mit $prefix herumspielt wird wahrscheinlich ein seltsames Verhalten hervorrufen. Die gleichen Argumente gelten für Skripte wie die Debian-Paketierungshelfer, die sich auf das übliche $prefix stützen Semantik zu arbeiten.
Die sauberste Lösung ist daher die bash-4.1 Lösung. Sie haben grundsätzlich zwei saubere Möglichkeiten:Teilen Sie Ihr Paket in bootkritische und nicht bootkritische Teile auf oder lassen Sie Ihren configure -Skript bieten ein alternatives Präfix für die bootkritischen Teile, das standardmäßig auf / gesetzt ist , wobei $prefix übrig bleibt als /usr .
Diese Frage hat zwei verschiedene Ebenen, und Ihre Fragen scheinen alle auf die zweite Bedeutung zuzutreffen (das von Ihrer *.spec-Datei oder debian/rules oder einer *.pkg-Datei generierte Binärpaket). Soweit die Autotools besorgt sind, INTERESSIEREN SIE SICH NICHT. Sie dürfen nicht versuchen, in Ihrer configure.ac ein anderes Standardpräfix als /usr/local anzugeben. Die Angabe, wo Dinge installiert werden sollen, erfolgt in den Steuerdateien des Binärpakets und NICHT in der Datei configure.ac. Die Quelldistribution, die das von autoconf generierte Konfigurationsskript verwendet, sollte standardmäßig in /usr/local installiert werden, und alles andere ist ein Paketierungsfehler.
Wenn Sie eine Quelldistribution haben möchten, die der Benutzer verwenden kann, um sie einfach an einem bestimmten Ort auf einer bestimmten Plattform zu installieren, wäre es akzeptabel, ein Skript in den Tarball aufzunehmen, das dies tut. Beispielsweise könnten Sie ein Build-Skript einfügen, das in etwa so aussieht:
#!/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
was Standardargumente zum Konfigurieren für die Plattformen 'foo' und 'bar' angeben würde, aber es hört sich wirklich so an, als bezögen sich Ihre Fragen auf Steuerdateien für Binärpakete.