Cosa è in realtà $ RPM_BUILD_ROOT?

Question

Nel processo di creazione di un pacchetto RPM, devo specificare BuildRoot e in seguito verrà utilizzato in% install che esegue l'esplorazione di $ RPM_BUILD_ROOT. Penso sempre che $ RPM_BUILD_ROOT sia la falsa installazione di RPM per eseguire il packaging. Quindi, al momento dell'installazione utilizzando il pacchetto RPM, verrà installato nella posizione effettiva. Per esempio:

$RPM_BUILD_ROOT/usr/bin 

ho pensato che $ RPM_BUILD_ROOT è per il processo di confezionamento unico, e per certi versi RPM può distinguere il $ RPM_BUILD_ROOT e l'effettivo percorso di installazione quando l'utente esegue "rpm -ivh pacchetto.rpm" volontà essere/usr/bin.

Ma recentemente, leggendo alcuni documenti, è suggerito che $ RPM_BUILD_ROOT è la posizione effettiva che verrà installata e $ RPM_BUILD_ROOT è specificato dall'utente con l'impostazione della variabile di ambiente $ RPM_BUILD_ROOT per consentire agli utenti di installare il pacchetto nelle loro posizioni di desiderio. In caso contrario, $ RPM_BUILD_ROOT sarà nullo e verrà installato nella posizione predefinita. Nel caso precedente, è/usr/bin. Pertanto, $ RPM_BUILD_ROOT non è solo per il processo di packaging o "installazione falsa", ma è un modo in cui l'utente può definire il percorso di installazione, in modo simile alla posizione della cartella selezionata in Windows.

Non so che il mio modo di pensare sia corretto o meno. Qualcuno può verificare? Grazie in anticipo.

Answer 1

$RPM_BUILD_ROOT (o il file equivalente macro %{buildroot} SPEC) sempre tiene la directory in cui RPM cercherà tutti i file al pacchetto. Gli script RPM (ad esempio lo script che comprime le pagine del manuale) utilizzeranno anche quel valore per sapere dove cercare i file che sono stati appena installati. Normalmente, questo valore non è vuoto e contiene una posizione lontana dalle directory di sistema, di solito da qualche parte sotto /tmp o /var/tmp.

L'autore del file SPEC dovrebbe fare in modo che make install (o qualsiasi altra cosa di installazione del software in questione sta usando) collocherà i file sotto $RPM_BUILD_ROOT, con la stessa gerarchia che deve essere utilizzato quando il software è finalmente installato. Per esempio. per fare in modo che RPM installi ls in /bin/ls, la sezione del file SPEC %install deve assicurarsi che ls sia inserito in $RPM_BUILD_ROOT/bin/ls.

Anche l'autore del file SPEC utilizza il tag BuildRoot: per specificare una posizione corretta. In alternativa, il sistema di build potrebbe avere un file di configurazione RPM rpmrc con una voce appropriata. Nel any case la radice di build dovrebbe essere impostato, in modo tale che:

• utenti normali saranno in grado di costruire il pacchetto sorgente.

• Se il superutente crea il pacchetto sorgente, il processo di compilazione non distruggerà alcun file di sistema, a meno che il superutente non installi il pacchetto binario risultante. E sì, ci può essere una buona ragione per creare dei pacchetti come root - ad esempio, l'esecuzione della suite di test glibc completa richiede i privilegi root per alcuni test.

Detto questo, RPM può e crea un pacchetto con una variabile radice di compilazione vuota. In tal caso, sia l'installazione di build che le posizioni di destinazione finali coincideranno. Una potenziale chiamata ad es. make install utilizzerà le ubicazioni predefinite, quindi copiando i file di sistema in ad es. /usr/lib se eseguito con privilegi sufficienti.Inoltre, avere /usr/bin/* nella sezione %files estrarrà felicemente l'intero contenuto della directory di compilazione dell'host /usr/bin/ nel pacchetto binario.

Bottom line:

• Non utilizzare mai una radice accumulo vuoto.

• Non compilare pacchetti come root a meno che non ci sia assolutamente nessun altro modo.

Answer 2

il file ~/.rpmmacros definisce i percorsi per utente:

%_topdir %(echo $HOME)/rpmbuild 
%_tmppath %{_topdir}/tmp 

e si può anche definirli con i parametri della riga di comando rpmbuild:

rpmbuild --define '_topdir /home/username/rpmbuild'