Czy powinienem umieścić aplikację w / usr / local lub / usr / local / share?

21

Jakie są „standardy” - czy powinienem umieścić aplikację (nie tylko binarną, ale całą dystrybucję) w / usr / local lub / usr / local / share.

Na przykład scala lub weka - zawiera przykłady, pliki binarne, biblioteki i tak dalej. Tak by było

/usr/local/scala-2.9.1 

lub

/usr/local/share/scala-2.9.1

Ponieważ jestem jedynym administratorem, nie jest to dla mnie wielka sprawa, ale wolę używać czegoś, co jest powszechnie używane, a nie własnych obyczajów.

Ważne: nie pytam o przypadki, w których powinieneś podzielić aplikację na / usr / local / bin, / usr / local / lib i tak dalej. Pytam raczej o przypadek, w którym musisz zachować jeden katalog główny dla całej aplikacji.

Greenoldman
źródło
6
Myślę, że / opt jest bardziej zwyczajowe w tego rodzaju kontekście.
Faheem Mitha,
@Faheem Mitha, bardzo dobry punkt. Dzięki tobie znalazłem takie wyjaśnienie drzewa katalogów „/ opt / 'provider”, podobne do sposobu, w jaki Windows zainstaluje nowe oprogramowanie we własnym drzewie katalogów C: \ Windows \ Progam Files \ „Nazwa programu” z linuxtopia.org/ online_books / linux_beginner_books / ... mógłbyś proszę ? dodać komentarz jako odpowiedź, więc chciałbym oznaczyć ją jako odpowiedź Dziękuję.
greenoldman
@greenoldman: też proszę sobie sprawę, że utrzymanie wszystkich plików w jednym katalogu jest nie „standard” sposobem zainstalowania aplikacji w systemie Unix. /optjest rzeczywiście dobrym rozwiązaniem, ale to nie „powszechnie używane” przez tradycyjnego oprogramowania Unix / Linux. Istnieją świetne powody, aby podzielić pliki na wiele katalogów, a także odróżnić je /usrod/usr/local
MestreLion
Na przykład, utrzymywanie wszystkich plików wykonywalnych ze wszystkich aplikacji w jednym /usr/bin(lub /usr/local/bin) pozwala $ PATH na dostęp do całego oprogramowania bez konieczności edytowania go dla każdego oprogramowania, koncepcja, która nie istnieje w systemie Windows
MestreLion

Odpowiedzi:

19

Myślę, że / opt jest bardziej standardowy w tego rodzaju kontekście. Odpowiednia sekcja Standardu hierarchii systemu plików jest cytowana poniżej.

Dystrybucje mogą instalować oprogramowanie w / opt, ale nie mogą modyfikować ani usuwać oprogramowania zainstalowanego przez lokalnego administratora systemu bez zgody lokalnego administratora systemu.

 Uzasadnienie Zastosowanie / opt w oprogramowaniu dodatkowym jest dobrze ugruntowaną praktyką w społeczności UNIX. Interfejs binarny aplikacji System V [AT&T 1990], oparty na definicji interfejsu System V (wydanie trzecie), zapewnia strukturę / opt bardzo podobną do zdefiniowanej tutaj.

Intel Binary Compatibility Standard v. 2 (iBCS2) również zapewnia podobną strukturę dla / opt.

Zasadniczo wszystkie dane wymagane do obsługi pakietu w systemie muszą znajdować się w / opt /, w tym pliki przeznaczone do skopiowania do / etc / opt / i / var / opt /, a także zastrzeżone katalogi w / opt.

Drobne ograniczenia dystrybucji za pomocą / opt są konieczne, ponieważ możliwe są konflikty między oprogramowaniem zainstalowanym w dystrybucji a oprogramowaniem zainstalowanym lokalnie, szczególnie w przypadku ustalonych nazw ścieżek znalezionych w niektórych programach binarnych.

Struktura katalogów poniżej / opt / jest pozostawiona programowi pakującemu oprogramowanie, chociaż zaleca się, aby pakiety były instalowane w / opt // i były podobne do wytycznych dla / opt / package. Prawidłowym powodem odejścia od tej struktury są pakiety wsparcia, które mogą mieć pliki zainstalowane w / opt // lib lub / opt // bin.

Faheem Mitha
źródło
5

Powinieneś używać tylko /usr/local/sharedo plików, które nie są specyficzne dla konkretnej wersji architektury / systemu operacyjnego.

Potem to zależy od ciebie czy rozpowszechniać pliki pomiędzy istniejących podkatalogów /usr/locallub jeśli utworzyć nowy katalog w dedykowany /usr/local(choć ta ostatnia wola nie istnieje już na wykonywalny PATHThe LD_LIBRARY_PATHani MANPATH).

Spójrz na FHS

symcbean
źródło
Dziękuję Ci. Jeśli więc jest to analogia z systemu Windows, powinien to być / usr / local / SPECIAL_APP, a wewnątrz powinny znajdować się jego podkatalogi, prawda?
greenoldman
@greenoldman: nope. Nie analogia będzie pasować, ponieważ system Windows i Linux stosować różne modele: W oknach, zwykle przechowywać wszystkie pliki w jednym katalogu, gdzie w Linuksie zazwyczaj podzielić je na bin, share, lib, etc
MestreLion
3

/optstało się powszechne, zwykłym miejscem było /usr/local/lib/<package>.

Miś
źródło
1
Z tego, co przeczytałem, / opt jest dość powszechny, tylko nie jest szeroko stosowany, ale nie jest to zaskoczeniem, jeśli pomyślisz o ilości pakietów dostępnych w repozytoriach.
greenoldman
0

Podczas instalowania aplikacji lokalnych istnieje wiele opcji w zależności od tego, jak chcesz uzyskać dostęp i aktualizację. Należy również zauważyć, że niektóre metody przypominają system, który już masz, a niektóre są bardziej ad-hoc. Sugerowałbym, że „najlepsze” rozwiązania ułatwiają zarządzanie.

Podzieliłem tę odpowiedź na podstawie liczby pakietów, dla których zostaną wykonane niestandardowe instalacje. Podział opiera się na moich własnych doświadczeniach. Te doświadczenia ważą czas potrzebny na zarządzanie paczkami oraz ryzyko związane z popsuciem czegoś. Nie chodzi mi o to, że mam wiedzę o wspólnych standardach, ale mam na myśli ten punkt odniesienia, na który należy zwrócić uwagę przy podejmowaniu decyzji.

Tylko dla kilku pakietów chciałbym umieścić dodatkowe pakiety/opt których nie są w stanie przeszkodzić wszystkim innym, więc nic nie może ich zepsuć i mogą zepsuć coś innego. Jest to metoda, której używam na moim serwerze NAS. Ta metoda jednak chroni pliki binarne od ŚCIEŻKI, więc musisz dodać je ręcznie. Działa to dobrze, jeśli jest tylko kilka pakietów do zainstalowania, ale staje się dość bałaganem, jeśli jest ich wiele.

Aktualizacja tutaj jest dość prosta, ponieważ po prostu nadpisujesz katalog.

Plusy:

  • prosty
  • szybki w konfiguracji
  • bez szans na wpływ na inne części systemu
  • odinstalowanie jest tak proste jak instalacja

Cons:

  • Staje się dość nużący, jeśli liczba pakietów do zainstalowania jest duża
  • Sprawia, że PATHwygląd Messy

W przypadku więcej niż kilku pakietów polecam użycie /usr/local/<your package>i sym-linkowanie pliku wykonywalnego z /usr/local/binlub w /usr/local/sbinzależności od tego, czy potrzebujesz uprawnień roota. Dzięki temu nie musisz zmieniać ŚCIEŻKI za każdym razem, gdy dodaje się coś nowego, aby ŚCIEŻKA pozostała czysta. Jest to metoda, której używam na moim laptopie Arch do wszystkich pakietów innych niż pacman i pakietów AUR.

Aktualizacja odbywa się poprzez zastąpienie katalogu pakietu i sprawdzenie, czy dowiązanie symboliczne jest nadal poprawne, i naprawienie, jeśli nie jest.

Plusy

  • Nie robi PATHbałaganu
  • Nie wpływa na system podstawowy
  • Nadal bardzo proste jest usunięcie wszystkich dodatków i powrót do czystego systemu podstawowego

Cons:

  • Więcej pracy do skonfigurowania
  • Usunięcie tylko jednego pakietu wymaga trochę wyszukiwania

Dla wielu paczek . Ponieważ nie jest to przypadek, którego chcesz, przedstawię to krótko. Polecam podział pakietu w bin, lib, share, itd. I ich instalację /usr/local. Ma to na celu utrzymanie struktury w czystości. Możesz także określić, kto może pisać gdzie i więcej. Na przykład nie chcesz, aby ludzie inni niż root modyfikowali plik wykonywalny.

Tutaj aktualizacja staje się nieco trudniejsza, ponieważ musisz pisać do więcej niż jednego katalogu. Poleciłbym spakowanie całości i pozwolenie kierownikowi paczki zająć się resztą.

Udział

shareSam katalog jest dla architektury niezależnych plików jak zauważono w Faheem za linkiem i plików zależy od architektury powinien udać się do lib, lib32, lib64, itd.

Lauri Tšili
źródło
Udzielanie porad na podstawie liczby paczek nie jest przydatne; skąd mam wiedzieć, do której grupy należy moja paczka?
Alois Mahdal
Ponadto, gdy powiesz „jest zalecane”,
odwołaj się
A tak na marginesie, nie widzę, jak in / opt miałoby mniejsze szanse, że coś zepsuje twoją aplikację, niż kiedy zostanie ona przeniesiona do / usr itp. Zaniepokojenie innych aplikacji polega bardziej na poprawnym nazywaniu rzeczy i braku błędów w instaluj skrypty.
Alois Mahdal
Zdecydowanie chodzi o nazewnictwo, które sprawia, że ​​wszystko się psuje. Jest to coś, czego doświadczyłem w przeszłości i dlatego lubię trzymać moje „dodatkowe” paczki z dala od wszystkiego innego. Nadal nie chcę, żeby to wyglądało brzydko.
Lauri Tšili
I tak, masz rację co do „jest to zalecane”, jak możesz zobaczyć z mojej odpowiedzi Użyłem „polecam” wszędzie indziej. Poprawiłem pisownię i wyjaśniłem, dlaczego polecam coś. Znowu jest to tylko moja perspektywa, a nie ostateczna odpowiedź.
Lauri Tšili