Co to jest RPM_BUILD_ROOT?

Question

W trakcie budowania pakietu RPM, muszę określić BuildRoot, a później zostanie użyty w% install, który invovles $ RPM_BUILD_ROOT. Zawsze uważam, że RPM_BUILD_ROOT jest fałszywą instalacją RPM do pakowania. Następnie, przy instalacji przy użyciu pakietu RPM, zainstaluje się w rzeczywistej lokalizacji. Na przykład:

$RPM_BUILD_ROOT/usr/bin 

myślałem że $ RPM_BUILD_ROOT jest tylko dla procesu pakowania, a pod pewnymi względami RPM można odróżnić $ RPM_BUILD_ROOT i rzeczywistą lokalizację instalacji, gdy użytkownik wykonuje „rpm -ivh pakiet.rpm” będzie be/usr/bin.

Jednak po przeczytaniu niektórych dokumentów sugeruje się, że RPM_BUILD_ROOT jest rzeczywistą lokalizacją, która zostanie zainstalowana, a RPM_BUILD_ROOT jest określona przez użytkownika z ustawieniem zmiennej środowiskowej $ RPM_BUILD_ROOT, aby umożliwić użytkownikom instalację w ich pożądanych lokalizacjach. W przeciwnym razie wartość $ RPM_BUILD_ROOT będzie równa zero i zostanie zainstalowana w domyślnej lokalizacji. W powyższym przypadku jest to/usr/bin. Tak więc RPM_BUILD_ROOT nie służy tylko do pakowania lub "fałszywej instalacji", ale jest sposobem na zdefiniowanie lokalizacji instalacji, podobnie jak w przypadku wybrania lokalizacji folderu w systemie Windows.

Nie wiem, czy moje myślenie jest poprawne, czy nie. Czy ktoś może to zweryfikować? Z góry dziękuję.

Answer 1

$RPM_BUILD_ROOT (lub równowartość %{buildroot} SPEC plik makro) zawsze posiada katalog, w ramach którego RPM będzie szukać wszystkich plików na opakowaniu. Skrypty RPM (np. Skrypt, który kompresuje strony podręcznika) będą również używać tej wartości, aby wiedzieć, gdzie szukać plików, które właśnie zostały zainstalowane. Zwykle ta wartość nie będzie pusta i zawiera lokalizację z dala od katalogów systemowych - zwykle gdzieś poniżej /tmp lub /var/tmp.

Autor pliku SPEC powinien upewnić się, że make install (lub jakikolwiek instalator, którego to oprogramowanie używa) umieści wszystkie pliki pod numerem $RPM_BUILD_ROOT, z tą samą hierarchią, która powinna być używana, gdy oprogramowanie zostanie ostatecznie zainstalowane. Na przykład. Aby zainstalować RPM ls w /bin/ls, sekcja pliku SPEC powinna zawierać się w pozycji ls w $RPM_BUILD_ROOT/bin/ls.

Autor pliku SPEC powinien również użyć znacznika BuildRoot: do określenia właściwej lokalizacji. Alternatywnie, system kompilacji może mieć plik konfiguracyjny RPM rpmrc z odpowiednim wpisem. W any case korzeń build powinien być ustawiony tak, aby:

• Zwykli użytkownicy będą mogli zbudować pakiet źródłowy.

• Jeśli superużytkownik kiedykolwiek zbudował pakiet źródłowy, proces kompilacji nie zbrzydzi żadnych plików systemowych, chyba że superużytkownik zainstaluje wynikowy pakiet binarny. I tak, może istnieć dobry powód do budowania niektórych pakietów jako root - na przykład uruchomienie pełnego zestawu testowego glibc wymaga root uprawnień do niektórych testów.

Powiedział, że RPM może i będzie budować pakiet z pustą zmienną root. W takim przypadku zarówno instalacja kompilacji, jak i lokalizacja docelowa będą się pokrywać. Potencjalne połączenie z np. make install użyje domyślnych lokalizacji, a więc przekręci pliki systemowe na przykład w /usr/lib, jeśli działa z odpowiednimi uprawnieniami.Dodatkowo, mając /usr/bin/* w sekcji %files, z przyjemnością ściągniesz całą zawartość katalogu budowania hosta /usr/bin/ do swojego pakietu binarnego.

Konkluzja:

• Nigdy nie należy używać pustego gromadzeniu korzeń.

• Nie buduj paczek jako root, chyba że nie ma absolutnie żadnego innego sposobu.

Answer 2

plik ~/.rpmmacros określa ścieżki na użytkownika:

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

i można również zdefiniować je z parametrami wiersza polecenia rpmbuild:

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