Jak naprawdę zainstalować plik tar.gz w systemie Linux - jak zarządzać ręcznie instalowanymi (lub samodzielnymi) aplikacjami?

Widzę wszystkie te linki wyjaśniające pakiety i .deb ... Wiem o tym ... i istnieje wiele przeszkód, aby pliki tar.gz działały (np .: aktualizacja-alternatywy dla Java lub ręczne upuszczanie pliku w / usr / local / bin (lub gdzie indziej, które wydedukowałem z godzin poszukiwań). Jeśli pakiety są tak inteligentne, to dlaczego tak mało aplikacji Linux jest dostępnych w pakietach lub .debs / rpms?

Mówię jako nowy użytkownik; Wiem, że eksperci prawdopodobnie wiedzą to lepiej (myślę, że mogę pobrać kompatybilną wersję Eclipse?). Podobnie jak netbeans i chrome .sh, eclipse jest prostym, uruchamialnym katalogiem, Java wymaga tego update-alternativesbiznesu, ale nie sądzę, że rejestruje się na „liście programów” Ubuntu / Debiana (rejestruje się jako polecenie) itp. (Wiem, że są to czasami dostępne w repozytoriach, ale jestem tylko zdezorientowany, dlaczego strony pobierania nie mają odpowiednich wyjaśnień).

Krótka historia: Jeśli pobierzesz lub skompilujesz plik tar.gz, jak mogę go zarejestrować w systemie? update-alternativeswydaje się rejestrować to jako polecenie, w Ubuntu nie pojawia się na pasku wyszukiwania. W Debianie mogę ręcznie dodać skrót do programu uruchamiającego GNOME 2. Ale co powinienem naprawdę robić?

Edytować:

Więc po nieco więcej zabawy z nowymi rozwiązaniami, mogę trochę udoskonalić mój „problem”:

Jak mam zarządzać ręcznie instalowanymi programami? Firefox i Eclipse to moje dotychczasowe przykłady (nie pobieram dużo rzeczy). Obaj mogą zabraknąć pudełka, co mi się podoba. Poza tym, gdzie mam je instalować? Widzę, że Eclipse ma własne instrukcje, ale wolałbym robić wszystkie moje „ręczne pakiety” w ten sam sposób.

1. Po kilku badaniach postanowiłem wprowadzić te programy /usr/local/bin.
2. Od jak zainstalować Eclipse , pomyślałem, że aby uzyskać coś, co pojawi się w programie uruchamiającym, muszę umieścić xxx.desktopplik ~/.local/share/applications/. Czy nazwa tego pliku .desktop ma znaczenie?
3. Rzeczy z narzędziami automatycznymi (szukam pliku configurelub unix/configurepliku) zadziałają dobrze. Niektóre punkty badawcze, których powinienem użyć, CheckInstallaby śledzić to wszystko.
4. Powinienem użyć update-alternativesdo zarejestrowania ścieżek. Z tego wątku Java wydaje się, że tworzę link od /usr/bin/javado /usr/lib/jvm/jdk.... Czy po instalacji tych „samodzielnych” aplikacji, takich jak Eclipse lub Firefox, zawsze powinienem łączyć się z nimi /usr/bin/[app]? A jeśli twierdzenie 1 jest prawdą, robiłbym takie rzeczysudo update-alternatives --install "/usr/bin/[app]" "[app]" "/usr/local/bin/[app]" 1

Czy te instrukcje są prawidłowe / dobry sposób na zarządzanie instalacjami ręcznymi? Czy są jeszcze jakieś kroki, które powinienem wykonać? Inne sugestie?

Dlaczego wiele aplikacji nie jest dostępnych w repozytoriach pakietów?

Może być wiele przyczyn:

• Nikt nie zadał sobie trudu, aby spakować aplikację.
• Nikomu nie wolno pakować aplikacji (np. Oracle nalega, aby być jedynym, który rozpowszechnia Javę ).
• Pakiet jest publikowany na licencji, która jest sprzeczna z wartościami dystrybucji.
• ...

Nie ma jednego powodu. Jeśli chcesz zobaczyć swoją ulubioną aplikację w menedżerze pakietów swojej dystrybucji, powinieneś potraktować każdą sprawę osobno. Spróbuj skontaktować się z deweloperami (na przykład na kanale IRC lub liście mailingowej) i zapytaj, jak możesz pomóc w pakowaniu.

Jak zainstalować tarball?

Plik tarball (pakiet .tar.gz) może zawierać wszystko. Dopóki go nie otworzysz, nie możesz założyć, jak go zainstalować. Ponownie do każdego pakietu należy podchodzić inaczej.

Poszukaj dokumentacji! Każdy (częściowo) przyzwoity pakiet zawiera instrukcje dotyczące instalowania aplikacji. Pierwszym odruchem zawsze powinno być poszukiwanie pliku tekstowego o nazwie README, INSTALL lub coś w tym rodzaju. Pomocne może być również sprawdzenie witryny wydawcy.

Ponieważ każdy pakiet jest inny, nie ma uniwersalnego sposobu na przetworzenie każdego archiwum na świecie. To tak, jakby poprosić o przepis, który działa na wszystkie składniki na świecie. Nie dzieje się.

Dobra znajomość twojego systemu, twojej dystrybucji i środowiska pulpitu pomoże, więc jeśli jest to uspokajające, rzeczy będą wyglądały coraz bardziej przewidywalnie, gdy będziesz spędzać czas w świecie linuksowym.

Specjalny przypadek: narzędzia automatyczne

W miarę jak projekty stają się większe, muszą zapewnić łatwe sposoby przejścia z kodu źródłowego na binarny do pełnej instalacji w systemie. Dlatego są dostarczane z wbudowanym systemem kompilacji, kolekcją skryptów wykonujących niezbędne czynności.

W świecie Linux / Open Source / Free Software jeden system kompilacji zyskał szersze zastosowanie: GNU Autotools . Jeśli kiedykolwiek będziesz mieć do czynienia z pakietem (n) open source, istnieje duża szansa, że ​​będziesz używać Autotools.

W najprostszym przypadku, oto jak zainstalować aplikację spakowaną z narzędziami automatycznymi:

• ./configure: Skrypt, który wygeneruje pliki Makefile odpowiadające Twojemu systemowi (często sprawdza również dostępność zależności).
• make: Kompilowanie kodu źródłowego zgodnie z wygenerowanymi wcześniej Makefiles.
• make install: Kopiuje pliki binarne do odpowiednich lokalizacji, tworzy dowiązania symboliczne i wszelkie inne kroki zdefiniowane przez programistę.

Notatki

• configureskrypty mają zwykle wiele opcji, takich jak używany kompilator lub sposób definiowania katalogu docelowego. Jeśli potrzebujesz elastyczności, warto na to spojrzeć ./configure --help.
• Nawet jeśli jesteś pewien, że to Autotools i dobrze o tym wiesz, zawsze zaczynaj od przeczytania dokumentów (CZYTAJ, ZAINSTALUJ ...)

Odpowiedz na aktualizację w pytaniu

To, o co prosisz, nie ma jednoznacznej odpowiedzi. Każdy tutaj może mieć opinię na temat tego, co stanowi „dobrą praktykę”, ale pod koniec dnia tylko Ty możesz znaleźć to, co działa dla Ciebie . Gdyby była łatwa odpowiedź, nie zadałbyś pytania. Twoja dystrybucja odpowiedziałaby na to za ciebie.

To powiedziawszy, oto kilka osobistych uwag.

• W moim systemie rezerwuję /usr/local/binna pakiety zainstalowane przez mojego menedżera pakietów. Wszystko, co kompiluję / instaluję ręcznie, wchodzi /opt. Jest to szczegół, ale pomaga uniknąć poważnych bólów głowy w przypadku kilku wersji tego samego programu.

• xxx.desktopi ogólnie problemy z GUI są specyficzne dla używanego środowiska pulpitu. Jeśli to działa w twoim systemie, świetnie. Ale nie można go uogólnić na wszystkie środowiska dostępne w Uniksie.

• /usr/local/binma tę zaletę, że jest już w ŚCIEŻCE . Jeśli chcesz użyć innego katalogu (jak /optsugeruję), pamiętaj o dołączeniu go do ŚCIEŻKI. Jeśli nie wiesz, jak to zrobić, otwórz terminal i wykonaj następujące czynności w terminalu (nie jest to najładniejszy sposób, ale nie wiedząc nic o twoim systemie, nie mogę zasugerować niczego innego):echo 'export PATH=$PATH:/opt' >> ~/.bashrc

Myślę, że trzeba wyjaśnić z siebie to, co chcesz „zarejestrować” go z .

Aby wyjaśnić - i nie staram się być inteligentnym - „linux” jest oczywiście jądrem, a jądro nie wie ani nie interesuje się żadnym oprogramowaniem przestrzeni użytkownika w twoim systemie poza init. O czym tu mówimy?

Wspominasz o kilku różnych dystrybucjach. Czasami buduję oprogramowanie ze źródła, nawet jeśli jest ono dostępne w repozytorium, ponieważ chcę ustawić niektóre opcje konfiguracji, które nie są ustawione w dystrybucji. Jedyny problem, jaki mam z tym, to to, że jeśli pakiet jest warunkiem wstępnym do czegoś innego, rzeczywiście muszę to zarejestrować w systemie pakowania , aby uniknąć przypadkowego zainstalowania pakietu dystrybucyjnego na szczycie tego, który zbudowałem. W systemach opartych na fedora / rpm odbywa się to za pomocą rpm -i --justdb <package>. Nie robię tego na systemach opartych na debian / apt; zamiast tego po prostu wymuszam instalacje w razie potrzeby, co może być leniwe - wygląda na to, że jest to lepszy sposób, tworząc atrapę, która udaje, że spełnia wszystkie wymagania wstępne. Jest to coś w rodzaju sugestii m0nhawk, aby faktycznie stworzyć pakiet ze źródła .tar.gz - z wyjątkiem nieco prostszego (będę szczery i powiem, że wcale nie lubię sugestii m0nhawk).

Wygląda na to, że masz inne problemy poza systemem pakowania. Nie jest dla mnie jasne, co to jest, chociaż wspominasz o środowisku pulpitu (np. Gnome). Są heterogeniczne, więc po prostu nie ma jednej odpowiedzi na pytanie: „jak to zrobić na Linuksie” - nie jest nawet pytanie „jak to zrobić na Ubuntu” lub „jak to zrobić na gentoo ”- jest to pytanie„ jak to zrobić dla pulpitu gnome ”lub„ jak to zrobić na pulpicie XFCE ”itp. Moim zdaniem jedyną kwestią jest kwestia wyrzutni, o których wspomniałeś, chciałbym wierzyć, że każdy DE zapewnia prosty sposób na zrobienie tego (ale nie będzie dokładnie tak samo, ponieważ są różne).

Są też usługi, którymi zarządza system init (np. Systemd lub upstart). To pytanie jest w rzeczywistości serią powiązanych pytań dotyczących, potencjalnie:

• system pakowania, np. apt lub yum
• system init, np. systemd lub upstart
• środowisko pulpitu, np. KDE lub Unity
• przeglądarka plików, np. nautilus lub konqueror
• ?????

Jednym z powodów, dla których nie może istnieć jedno proste zunifikowane rozwiązanie (chociaż standard XDG może zawierać niektóre jego części), jest to, że „linux” nie jest jednym prostym zunifikowanym systemem operacyjnym i wyobrażam sobie, że zdecydowana większość jego użytkowników tak woli. Często w ogóle nie używam DE i nigdy nie używam przeglądarki plików, z której pochodzą itp.

Ponownie, naprawdę staram się być w tym pomocny, a nie tylko pontyfikat: jeśli są problemy, które chcesz rozwiązać tutaj, będziesz musiał dokładniej zastanowić się, jakie są te problemy i jakie oprogramowanie jest z nimi związane (poza „linux”) „) jeśli chcesz je rozwiązać.

Myślę, że podstawowym powodem całego problemu jest to, że sam system Linux nie zawiera „rejestru” jako takiego. Plik wykonywalny to wszystko, czego naprawdę potrzebujesz, aby coś uruchomić. Jeśli nie chcesz określać pełnej ścieżki do pliku wykonywalnego, większość powłok będzie ich szukała w katalogach wymienionych w zmiennej $ PATH w twoim środowisku. Może być nieco bardziej skomplikowany z połączonymi bibliotekami i tak dalej, ale zwykle nie musisz zagłębiać się tak daleko.

Różne dystrybucje Linuksa ustandaryzowały różne układy plików i systemy zarządzania pakietami, w tym tkwi problem. Redhats używają rpm , Debians / Ubuntu używają pakietów deb. Arch poszedł też własną drogą . Z perspektywy projektów oprogramowania, jeśli nie chcesz być objęty dystrybucją, twoja baza użytkowników znajduje się w całości w jednej dystrybucji lub w produkcie komercyjnym, który ma być łatwy w instalacji dla wszystkich, to prawdopodobnie jedyne punkty, które zaczniesz budować różne pakiety.

W rzeczywistości źródłowy plik tar.gz, który buduje, gccjest prawdopodobnie najlepszą definicją wspólnego „pakietu Linux”. Jądro Linuksa z niektórymi narzędziami GNU i GCC o wspólnym mianowniku między wszystkimi różnymi odmianami systemów operacyjnych opartych na Linuksie, które można uzyskać.

Nie posunąłbym się nawet do stwierdzenia, że ​​„tak mało” rzeczy jest dostępnych jako pakiety, ponieważ coś, czego szukasz, nie jest. (a może dystrybutor postanowił nie zawracać sobie głowy tym całym zamieszaniem? Jak Chrome i jego własny proces aktualizacji). Jest tak wiele pakietów wokół dla tak wielu różnych pakietów systemów dla tak wielu architekturach na tyle wolnego oprogramowania jej nie śmieszne .

Jeśli zbudowałeś coś, co nie jest dostarczane jako pakiet dla twojej dystrybucji Linuksa, lub obsługuje opcję budowania jako pakiet, najlepszym sposobem na „zarejestrowanie” go jako prawdziwego pakietu jest zbudowanie dla niego pakietu, określając gdzie wszystkie pliki powinny iść w zależności od wybranego systemu pakietów i zainstalować go w ten sposób. Bądź duszą i wnieś swój projekt opakowań z powrotem do projektu, aby inni mogli z niego skorzystać.

W sieci dostępne są różne przewodniki dotyczące budowania pakietów . Debian jest jednym z nich .

Jeśli wszystko, co chcesz zrobić, to uruchomić skompilowany pakiet, może dodać ścieżkę binarną do swojego $PATH?

Jeśli robisz coś innego, co to jest?

Chciałbym dodać, że możesz również link do dowiązania ~/bin/zamiast /usr/bin. *.desktoppliki można umieścić w ~/.local/share/applications/lub /usr/share/applications/. Tylko korzystam z komputera i lubię unikać dotykania plików systemowych (wszystkiego poza moim katalogiem domowym) tak bardzo, jak to możliwe.

Oczywiście, gdy umieścisz rzeczy w odpowiednikach „katalogu domowego”, nie pojawią się one dla innych użytkowników.

Oto, co jest zawarte w domyślnej wersji ~/.profiledebian wheezy:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi