Skąd mam wiedzieć, gdzie umieścić rzeczy w systemie Linux?

Instalacja czegoś w systemie Windows wymaga kliknięcia przycisku. Ale za każdym razem, gdy próbuję zainstalować coś w systemie Linux, czego nie można znaleźć w APT, tak się mylę.

Pobierasz spakowany folder, co wtedy? Jeśli masz szczęście, istnieje CZYTELNIK, odnoszący się do dokumentacji, która może ci pomóc, jeśli masz szczęście.

Jaka jest magiczna sztuczka podczas „instalowania” rozszerzeń i aplikacji, których nie ma w APT?

Uwielbiam Linux, ale ten problem prześladuje mnie każdego dnia.

Jeśli jest to oprogramowanie, które przestrzega standard hierarchii systemu plików niż należy umieścić go w /usr/locali odpowiednie podkatalogi (jak bin, lib, share, ...).

Inne oprogramowanie należy umieścić we własnym katalogu pod /opt. Następnie ustaw PATHzmienną tak, aby zawierała binkatalog lub dowolny katalog zawierający pliki wykonywalne, lub utwórz dowiązania symboliczne /usr/local/bin.

Nie ma prostej odpowiedzi na to pytanie, ale mogę przedstawić ogólny zarys tego, jak to działa:

Większość oprogramowania dla Linuksa jest dostarczana przez autorów („upstream”) w formie kodu źródłowego. Dzięki temu każdy, kto ma kompilator dla konkretnej platformy i konfiguracji systemu, może pobrać kod źródłowy i samodzielnie go skompilować. Niestety, wiele programów opiera się na funkcjach innych programów i bibliotek oprogramowania (zależności).

Oprogramowanie systemu Windows jest zwykle dostarczane w formie wstępnie skompilowanej. Oznacza to, że istnieje jeden ogólny plik wykonywalny dla wszystkich komputerów z systemem Windows, a zależności często występują w pakiecie instalacyjnym.

Dystrybucje systemu Linux pobierają kod źródłowy, prekompilują go dla Ciebie i oferują również jako pakiet. Pakiet nie zawiera zależności, ale odnosi się do nich i zmusza system pakietów do ich zainstalowania (co może czasem prowadzić do bałaganu, którego prawdopodobnie już doświadczyłeś).

Jeśli nie ma prekompilowanego pakietu, zawsze możesz pobrać kod źródłowy i samodzielnie go skompilować. Przez większość czasu będą działać:

./configure
make
(sudo) make install (or sudo checkinstall)

Wiersz ./configure określa etap procesu kompilacji (i wyrzuca błędy, jeśli zależności nie są spełnione). Linia make wykona Makefile, skrypt, który kompiluje wszystkie części programu.

Tradycyjnie używałbyś make install, aby następnie zainstalować oprogramowanie. Zwykle umieszcza to pliki wykonywalne w / usr / local / bin.

Ponieważ używasz apt, bardzo polecam pobranie checkinstall. Możesz go użyć zamiast make install, a wygeneruje on pakiet .deb. To znacznie ułatwia późniejsze usunięcie oprogramowania.

Zauważ, że istnieje kilka innych systemów kompilacji, na przykład cmake; a niektóre oprogramowanie jest wstępnie skompilowane, ale rozpakowane (w takim przypadku można je uruchomić bezpośrednio z rozpakowanego folderu); a niektóre oprogramowanie jest zbiorem skryptów, które musisz sam uruchomić. Świeży kod z SVN czasami przychodzi bez skryptów konfiguracyjnych, więc najpierw musisz uruchomić łańcuch narzędzi autoconf ... itd. Itd. Widzisz, istnieje wiele wyjątków od reguły, ale przy odrobinie doświadczenia będziesz w stanie powiedz, co zrobić z większością tajemniczych pobrań. Configure-Make-Checkinstall to dobry pierwszy start.

PS. Spędź weekend lub dwa, aby nauczyć się programować, a wszystko stanie się bardzo oczywiste :-)

PPS. Możesz się zastanawiać, dlaczego autorzy oprogramowania dla Linuksa nie dostarczają wstępnie skompilowanych pakietów zamiast kodu źródłowego. Czasami tak robią. Ale różne platformy i dystrybucje Linuksa mają swoje własne formaty pakietów i reguły systemu plików, więc jako programista musiałbyś dostarczać pakiety dla każdej możliwej konfiguracji - co jest uciążliwe. Pakiety Ubuntu są jednak często najłatwiejsze do znalezienia - powinieneś dowiedzieć się, co to jest PPA i jak to działa!

Powinieneś sprawdzić checkinstall . Zamiast

./configure
make
sudo make install

ty robisz

./configure
make
sudo make checkinstall

i będziesz mógł zarządzać tym pakietem tak, jakbyś zainstalował go za pośrednictwem apt.

Istnieje uzasadniony, rozsądny powód, który jest tak mylący (istnieje również irytujący powód artefaktu) ...

Unix ma historię wielu użytkowników i większość użytkowników nie miała dostępu do instalowania aplikacji poza obszarami, do których przyznano im określony dostęp.

Więc teoria byłaby taka, że ​​zbudujesz coś w swoim katalogu domowym, a następnie skopiujesz go do obszaru, nad którym panowałeś (własnego obszaru projektu lub wspólnego obszaru).

Komputery z systemem Windows są zazwyczaj systemami dla jednego użytkownika i nie mają tego ograniczenia, wszystko idzie w plikach programu bez względu na wszystko.

Jest też głupi, irytujący fakt, że za każdym razem, gdy pojawiała się nowa wersja Uniksa, twórcy uważali za konieczne zmianę lokalizacji, ale stare musiały nadal istnieć w przypadku automatycznych skryptów. To daje ci kilka powiązanych katalogów służących temu samemu celowi.

System init jest jeszcze gorszy.