Gdzie powinienem umieścić oprogramowanie, które sam kompiluję?


Odpowiedzi:


89

Ogólna zasada, przynajmniej w systemach o smaku Debiana:

  • /usr/localo rzeczy, która jest „w całym systemie” -ie /usr/localbywa zalega distro jest $PATH, i podąża standardową hierarchię katalogów z systemu UNIX /usr/local/bin, /usr/local/libitp

  • /optdo rzeczy, które nie mają zaufania do całego systemu, z prefiksów-ie na aplikacji /opt/firefox-3.6.8, /opt/mono-2.6.7i tak dalej. Rzeczy tutaj wymagają bardziej starannego zarządzania, ale także mniej prawdopodobne jest uszkodzenie systemu - i jest łatwiejsze do usunięcia, ponieważ po prostu usuwasz folder i go nie ma.


co ciekawe, wiele programów / aplikacji automatycznie sugeruje instalację, /optjeśli się je sudozainstaluje.
HongboZhu,

50

Jeśli naprawdę nie chcesz, aby to w ogóle przeszkadzało, nie umieszczaj go w żadnym miejscu $PATH.

Jeśli chcesz $PATH, przynajmniej upewnij się, że nie instalujesz /usr/local. Przekonałem się, że wiele programów wygląda tam, nawet jeśli jest zainstalowane przez dystrybucję /usr.

Mój ulubiony sposób instalowania niestandardowego oprogramowania znajduje się w moim $HOMEkatalogu. W ten sposób nie musisz używać sudodo niczego, i jest bardzo ładnie oddzielony od reszty twojego systemu. Na przykład:

mkdir ~/stage
./configure --prefix=/home/username/stage && make && make install

A jeśli chcesz, możesz dodać /home/username/stage/bindo swojego $PATH.


1
Zdecydowanie najlepszą opcją jest korzystanie z katalogu domowego. IMO.
bitek,

1
+1 uzgodnione. Lubię ~ / sbin dla skryptów bash / ruby ​​/ python, a ~ / opt / ... dla skompilowanych instalacji, z aliasami w ~ / bin.
Kris,

4
+1 za korzystanie z katalogu domowego, ponieważ upraszcza to; -1 za sugestię, aby unikać $ PATH - istnieją tam katalogi „zarezerwowane dla instalacji lokalnych” zgodnie ze standardami (np /usr/local.).
Riccardo Murri,

1
Moja sugestia, aby unikać / usr / local, była oparta na (nieco niejasnej) woli oryginalnego plakatu, aby nie ingerować w pakowane oprogramowanie. Ponieważ jest mnóstwo spakowanego oprogramowania, które „pomoże”, szukając w / usr / local lub w $ PATH, pomyślałem, że kwalifikuje się jako zakłócające. Ale tak naprawdę zależy to od indywidualnych potrzeb i celów danej osoby. / usr / local może być doskonałym wyborem w wielu sytuacjach.
Sandy,

nikt nie zauważył całkowicie nieporozumienia z literą „s” w komentarzu nr 2. które powinny zostać usunięte
meffect

20

FHS mówi, aby umieścić go w / usr / local, gdzie dystrybucje nie powinny go dotykać. /usr/local/bindla plików binarnych /usr/local/srcdla źródła i /usr/local/libbibliotek. Zobacz specyfikację FHS, aby uzyskać więcej informacji


Co z konfiguracją? Powiedzmy, że zainstalowałem MySQL bez korzystania z menedżera pakietów, czy powinienem nadal używać /etc/mysqldo konfiguracji?
Hubro

Właśnie zauważyłem, że /usr/local/etcdomyślnie jest folder, chyba powinienem go użyć ... :-)
Hubro

10

Przez większość czasu lubię umieszczać własne skompilowane rzeczy /opt. To trochę pseudo-standardowe miejsce. Możesz również rozważyć /usr/local, ale wolę, aby moje rzeczy były w 100% odizolowane.


1
dystrybucja zwykle umieszcza w / opt całkiem sporo rzeczy (zwykle pakiety własnościowe) / opt nie mówi, że nie może tego dotknąć. jednak mówi, że o / usr / local
xenoterracide

1
Nigdy nie widziałem, żeby dystrybucja wkładała coś /opt, ale widziałem wiele razy, gdzie /usr/localjest pełno śmieci, które pochodzą z dystrybucji
Scott Anderson

dystrybucje, których używam, lubię umieszczać java w / opt Widziałem tam również czytnik acrobat. jeśli umieszczają pliki w / usr / local, ignorują FHS, który mówi, że należy zabezpieczyć je przed nadpisaniem w aktualizacjach systemu.
Xenoterracide

Chyba każdy z nich. FHS jest fajny, ale myślę, że czasami jest ignorowany.
Scott Anderson,

Jedyne rzeczy, w których widziałem pakiety Distro, /usr/localto hierarchie katalogów podobne do tych w standardowym drzewie i być może indeksowanie plików takich rzeczy jak TeX.
Phil Miller,

9

Połóż je /usr/local/src.

To, co robię, to rozpakuj źródło w tym katalogu. Stworzy to ścieżkę podobną do

/usr/local/src/postgresql-8.3.7

Następnie tworzę dowiązanie symboliczne do tego:

/usr/local/src # ln -s  postgresql-8.3.7 postgresql

Zrób cały swój budynek /usr/local/src/postgresql.

Robienie tego w ten sposób pomaga, gdy trzeba przedzierać się między wersjami i dokumentami, której wersji używasz.


1
+1 za podanie uzasadnienia i sposobu, w jaki OP może je zastosować, w tym wersjonowanie.
samt

6

To mi przypomina, że ​​muszę częściej korzystać z checkinstall ! W ten sposób po prostu robię to, co zwykle

 ./configure
 make

śledzony przez

 sudo checkinstall

utworzyć plik .deb ...


2
Nie odpowiada na pytanie.
JBentley

5

Jeśli jest taka możliwość - sugeruję skompilowanie oprogramowania, a następnie utworzenie pakietu FC (sądzę, że używa yum do instalowania pakietów oprogramowania). Następnie możesz zainstalować ten pakiet własnego skompilowanego oprogramowania i usunąć go bez zepsucia całego systemu.


5

Jeśli chcesz w łatwy sposób zainstalować i usunąć kilka samodzielnie zbudowanych aplikacji, możesz użyć Stow jako prostego menedżera pakietów.


5

Zgodnie z FHS , /usr/local/jest używany do aplikacji skompilowanych ze źródła, podczas gdy /opt/jest używany do aplikacji innych producentów nieobsługiwanych przez dostawcę systemu operacyjnego.


4

Dwie rzeczy polecam:

System: użyj stow i zainstaluj w / usr / local / stow / package-version. Następnie możesz łatwo przełączać się między wersjami.

W moim domu lub jeśli nie mam uprawnień do zapisu / usr / local, osobiście instaluję programy w ~ / .local, co jest wskazane przez standard XDG .

Możesz także użyć stow lokalnie, chociaż nigdy tego nie zrobiłem :)


3

Mam trochę inną konfigurację niż większość ludzi, ponieważ robię dużo rozwoju. Mam katalog / home / jackson / bin /, w którym instaluję pliki, i edytowałem plik .bashrc, dodając:

export PATH=/home/jackson/bin/bin::$PATH
export LD_LIBRARY_PATH=/home/jackson/bin/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=/home/jackson/bin/lib/pkgconfig:$PKG_CONFIG_PATH

Nie zrobiłbym tego dla wszystkiego, ale jest to miłe podczas tworzenia.


3

W rzeczywistości nie jest tak trudno tworzyć deb lub rpm ze źródłowego archiwum. W ten sposób możesz skorzystać z funkcji menedżera pakietów swojej dystrybucji, aby utrzymać system w czystości. To właśnie robię przez większość czasu: po prostu stwórz trochę obrotów na minutę.


2

jeśli kompilujesz aplikację, możesz dodać jej ścieżkę do pliku zmiennej PATH env. nie wpłynie to na innych użytkowników.


Zastanawiam się, dlaczego głosowanie w dół? +1 do rodzaju „równowagi”
phunehehe

Zastanawiam się także, dlaczego :-). Użyłem tego samego rozwiązania do używania cscope, gdzie nie mam uprawnień do instalacji.
Hemant,

@phunehehe Prawdopodobnie dlatego, że nawet nie próbuje odpowiedzieć na pytanie. Pytanie dotyczy tego, gdzie umieścić oprogramowanie. Ta odpowiedź daje wskazówkę na temat tego, co można zrobić po umieszczeniu go gdzieś. Można to ulepszyć, podając sugestie dotyczące używanych folderów.
JBentley

2

Zawsze istnieje opcja „umieść to tam, gdzie należy”, ale najpierw napisz proste rpm.


1

Jeśli chcesz, aby Twoja aplikacja była dostępna dla wszystkich użytkowników w systemie i masz niezbędne uprawnienia, użyj / opt. Jeśli chcesz, aby aplikacja była dostępna tylko dla Ciebie (i użytkownika root), użyj / home / nazwa użytkownika


0

Najprostszym sposobem na to jest .src.rpmpobranie pakietu źródłowego ( dla RPMites), rozpakowanie go, zhakowanie nowego źródła / konfiguracji / czegokolwiek, zmianę wersji i skompilowanie. Zainstalowanie tego powoduje, że menedżer pakietów wie o nowym pakiecie, pozwala rozważyć jego zależności i odinstalować / zaktualizować.

Za pierwszym razem jest to obowiązkowe, ale jeśli pojawi się nowa wersja (lub jakaś krytyczna łatka), łatwiej jest ją zaktualizować. Kolejną korzyścią jest to, że możesz stworzyć własne repozytorium z lokalnym oprogramowaniem, które będzie udostępniane np. Przez maszyny w laboratorium.


0

Napisz RPM, nie jest to trudne, ma wytyczne, gdzie umieścić rzeczy i sprawia, że ​​odinstalowanie jest szybkie.

Jeśli to zrobisz, zainstaluj pliki pod /usri nie pod /usr/local, podobnie jak wszystkie inne pliki przechodzące przez system pakowania.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.