Jogger Minia

Strona w permanentnej budowie.

Wprowadzenie do repozytoriów w systemie GNU/Linux

Informacje o wpisie.

Opublikowano 27 grudnia 2011 o 10:44:41 w kategoriach: Miniblog, Poradniki, Słowo napisane, Zerojedynka.

17 komentarzy; Góra strony.

Trackback; Poprzedni wpis; Następny wpis.

Początkujący użytkownicy Linuksa mają zaskakującą zdolność do podejmowania prób samodzielnej kompilacji każdego jednego programu. Za każdym razem, kiedy się z takim delikwentem spotykam, mam ochotę odesłać go do jakiegoś tekstu, gdzie wprost napisane by było, że kompilacje należy zostawić ekspertom, a zwykłemu użytkownikowi wystarczy, że program zainstaluje z repozytorium.

Niestety, dotychczas na żaden dobry tekst spełniający te kryteria nie natrafiłem. Postanowiłem więc samodzielnie wypełnić tę lukę:

Wprowadzenie do repozytoriów w systemie GNU/Linux.

Może komuś się przyda. Jeżeli zaś chodzi o ewentualną krytykę, to prosiłbym o zwrócenie uwagi na trzy kwestie:

  1. Tekst jest przeznaczony dla początkujących użytkowników, więc starałem się unikać wchodzenia w szczegóły techniczne. Jeżeli jednak gdzieś mi się nie udało i jakiś fragment jest zbyt skomplikowany, to mile widziane jest zwracanie uwagi.
  2. Jeżeli znacie lepszej jakości materiały niż te, do których odsyłam w tabelce, to koniecznie dajcie znać.
  3. Jeśli gdzieś popełniłem jakiś rażący błąd merytoryczny, to krzyczcie.

Komentarze

Niech se newby używają Gentoo/Portage albo portów na FreeBSD. Świetna dokumentacja i każdy ogarnie, raczej w kompilowaniu nie ma nic złego: zwłaszcza, ze jest to nauka. Jednak całkowicie zgadzam się z Tobą, że bardzo często kompilowanie jest całkowicie niepotrzebne, może uświadomienie ludzi o tym nie zaszkodzi. :)

@pecet: zgadzam się. To, że napisałem iż jest wygodne dla początkujących (newbie) nie znaczy, że jest złe. Po prostu pozwala cieszyć się z kompilowania przy zachowaniu zalet dobrego systemu zarządznia pakietami / repozytorium. Nie miałem na myśli niczego negatywnego, po prostu napisałem że jest łatwe w zarządzaniu.

Rze co? o_O Tak się teraz porobiło?! Ja jako początkujący user Linuksa jakoś tak pięć lat temu bardzo chciałem mieć kontrolę nad tym, co mi się instaluje - ale z repozytoriów jak najbardziej. Bardzo ubolewałem, jak trzeba było coś kompilować samodzielnie - ponieważ w systemie brakowało niemalże wszystkiego, mało; skrypt czasem pisał mi po jednym brakującym elemencie co każde uruchomienie, które trwało kilkanaście minut... I tak kilka razy... Czyli ponad godzina spędzona na poszukiwaniu w repozytoriach właściwych bibliotek niezbędnych do kompilacji, po czym dopiero kompilacja właściwa... Do tego nieraz korzystałem z pomocy również i Twojej, jak pamiętasz, żeby w ogóle zrozumieć, co system mi usiłuje przekazać. Nie no, czyli teraz mamy pokolenie masochistów!

Co do "nie natrafienia na podobny tekst" - cóż, moim zdaniem dość dobrze jest to opisane (językiem dla zwykłych użytkowników) w dokumentacji np. Ubuntu, czy innych systemów, mających działać i być łatwo dostępnymi niczym są Win XP czy 7... Tam nawet nic o kompilacjach nie ma, jest tylko przedstawienie repozytoriów jako Wielkich Zasobów, Gdzie Jest Wszystko Lub Więcej, A Już Na Pewno Wszystko, Co Da Się Uruchomić Pod Tym Systemem (dla wygody WZGJWLWAJNPWCDSUPTS). :-)

A teraz co do artykułu - może się czegoś przy okazji nauczę.
Po pierwsze - czy instalacja takiego cacka jak Ipla (wymagająca środowiska AdobeAir) jest możliwa w jeden z przdstawionych przez Ciebie sposobów?

I drugi przykład, nieco mniej skomplikowany - komunikator Tlen, dystrybuowany przez Tlen.pl w postaci pliku *.bin wykonującego się graficznie w konsoli tekstowej. "Skryptoarchiwum" ;) to ma tez opcję odinstalowania Tlenu. Szczerze mówiąc, nie sądzę, żeby szło to dodać do/jako repo, natomiast też, w obydwu przypadkach, rzeczywiście nie ma mowy o kompilacji (Ipla wedle ich WWW wymaga tylko (poza Adobe) "ręcznego" spełnienia dwóch zależności pakietowych).

I w końcu: znalazłem programik DebOrphan (i nakładkę GTKOrphan). Znajduje mi ponad 60 pakietów, które wedle niego są osierocone i które do niczego w moim systemie nie sa używane. Pytanie brzmi, dlaczego Synaptic ich nie widzi jako niepotrzebnych (normalnie wykrywa takie pakiety, wystarczy kliknąć w przycisk "Stan" - są tam te, które można bezpiecznie odinstalować, bo program (-y), do którego (-ych) były wymagane, już został odinstalowany. Co więc tak naprawdę znajduje mi DebOrphan?

Aby kompilować popularny i powszechnie używany pakiet od podstaw musiałbym mieć dobry powód. Mogłaby nim być na przykład chęć posiadania kilku instalacji tego samego pakietu w systemie jednocześnie - na przykład jakiegoś konkretnego serwera o różnych konfiguracjach działającego jednocześnie na różnych portach. Albo mocno niestandardowa konfiguracja, której nie przewidzieli twórcy pakietu. Pewnie użyłbym do tego jakiegoś Slackware, które chyba zostało stworzone z myślą o takich działaniach.

W praktyce jako osoba zbyt leniwa pewnie użyłbym wirtualizacji na poziomie systemu operacyjnego (FreeBSD): minimalnym nakładem pracy uruchomił ez-jail i każdą odmianę tego samego serwera trzymał w innej maszynie wirtualnej: oddzielne środowisko procesów, sieci. Pewnie raz zbudował pakiet korzystając z portów po wyborze odpowiednich opcji, jeżeli pakiet systemowy nie wspierałby ich. Wbrew pozorom zarządzanie tym jest naprawdę proste, nawet jak dorzuci się do tego wirtualne systemy plików ZFS dla każdej maszyny.

W przypadku korzystania z repo/portów można korzystać z takich bajerów jak np. powiadamianie o zagrożeniach bezpieczeństwa. W przypadku ręcznej kompilacji oczywiście sami musimy być całkowicie czujni.

Czy istnieje problem w zamknięciu takich pakietów jak Skype, Tlen w paczce rpm i umieszczenie w repo? Nie jestem pewien, ale chyba Fedora wspiera takie repozytoria, bo dlaczego by nie?

Aha, nie jestem ekspertem i mogę się mylić. Raczej jak zwykle wszystko zależy od potrzeb i nie ma jednocześnie jednoznacznie dobrych / złych rozwiązań, wszystko zależy od konkretnego przypadku.

Czy istnieje problem w zamknięciu takich pakietów jak Skype, Tlen w paczce rpm i umieszczenie w repo? Nie jestem pewien, ale chyba Fedora wspiera takie repozytoria, bo dlaczego by nie?

Sam korzystam ze Skype, którego w wersji prawie najnowszej bez trudu znalazłem w domyślnych repozytoriach systemu (Mint Debian Edition = w dużym uproszczeniu całe repo Debiana plus nakładki Minta). Dodałem Operę, która udostępnia własne repozytoria. Tlen jednak nawet targzipa nie oferuje (nawet jeśli, jest w nim plik wykonywalny).

Debian (-owate) do tego ma (-ją) fantastyczną obsługę plików pakietów *.deb (nawet tych przetworzonych np. Alienem z innych, jak *.rpm) - instalator jest powiązany z menedżerem pakietów i sprawdza wszelkie zależności, wpisuje program do bazy i można go odinstalować równie łatwo, jak dowolny program zainstalowany z repozytorium. To duży plus, bo pojawiają się czasem gotowe kompilacje użytkowników, np. komunikator Psi lubi mieć takie wariacje na swój temat. Inna sprawa to zaufanie do twórcy takiej kompilacji...

Czy istnieje problem w zamknięciu takich pakietów jak Skype, Tlen w paczce rpm i umieszczenie w repo?

Z zamknięciem w paczce nie ma problemów, ale z umieszczeniem w repo — tak. Programy o zamkniętym kodzie źródłowym mają na tyle restrykcyjną licencję, że często nie pozwalają nawet na redystrybucję w niezmienionej formie. Nie można więc ich umieścić w repozytorium bez złamania tej licencji, a umowy na redystrybucję często nawet nie ma kto podpisać (np. za takim Debianem nie stoi żadna instytucja o osobowości prawnej).

Natomiast można utworzyć pakiet z odpowiednimi skryptami, który pobierze odpowiednie pliki i je zainstaluje. Tak są zrobione flashplugin-nonfree czy ttf-mscorefonts-installer w Debianie.

Marsjanin: Skype AFAIR jest w paczce .deb, więc wystarczy sobie taką paczkę wrzucić do lokalnego repo. O ile Tlena można zainstalować bezobsługowo, to można go wrzucić do paczki i stworzyć skrypt postinst, który zajmie się resztą. Analogicznie, skrypt postrm odpowiadałby za jego usunięcie. Taką paczkę do lokalnego repo i już.

W ostatnim akapicie ostatniej wiadomości piszesz chyba o gdebi. To jest wynalazek Ubuntu, który właściwie jest graficzną nakładką na dpkg -i, potrafiącą przy tym obsługiwać zależności.

Co do deborphan — man ;) , mogę też zaproponować mój tekst, w którym o nim wspominam: http://dug.net.pl/tekst/150/

Być może chodzi o gdebi, być może nie, gdyż przyzwyczaiłem się już niestety (tak, zrzędzę), że wiele z programów graficznych pod Linuksem wcale się nie chce przedstawić użytkownikowi. Na ten przykład "Narzędzie do obsługi dysków" przedstawia się graficznie (Pomoc/O...)... tak właśnie. Ja mam go w wersji 2.31.1 z dopiskiem "© 2007-2009 Red Hat, Inc.". Tyle wiem. Jeśli podejrzę aktywator w menu, to widzę, że wykonywane jest polecenie 'palimpsest' - jeśli jednak np. właśnie coś mi go odinstalowało, albo działam na kompie z kompatybilną, ale inaczej przemyślaną dystrybucją (np. z Fluxboksem zamiast Gnome), to za Chiny nie wiem, co mam zainstalować (ponownie). Można próbować obciążyć program i szukać go za pomoca top/htop... Podobnie jest z gdebi - mi przedstawiał się zawsze jako "instalator pakietów", czy jakoś podobnie.

Nieważne, czy to gdebi, czy nie, chodzi o to, że ma "połączenie z bazą danych, z której korzysta menedżer pakietów" - i Synaptic, apt-get i podobne potrafią go usunąć.

Tlena w Synapticu po instalacji nie widać. Żeby była jasność. Nie instaluje się też go bezobsługowo; program instalacyjny wyświetla licencję i wymaga jej akceptacji poprzez zaznaczenie [__OK__](w praktyce kliknięcie w enter).

Co do deborphan i mana: tl;dr - a nieco mniej bezczelnie, chodzi mi o to, że czy istnienie takiego programu tak naprawdę nie dowodzi, że menedżery pakietów po prostu w tej materii są do dupy? One powinny o to dbać. Mało; mają tę funkcję, ale jakoś tak wyszło, że mało efektywną, nieszczelną...

Jeszcze to, by było bardziej obrazowo:

Skype AFAIR jest w paczce .deb, więc wystarczy sobie taką paczkę wrzucić do lokalnego repo.

Otóż akurat Skype to ja mam w oficjalnym repo, ale załóżmy, że w zamian mówimy o programie, którego tam nie ma - np. o jakiejś małej modyfikacji Psi. Dążę do tego, że z tego, co zaobserwowałem, rzeczony gdebi robi tę robotę za mnie: zamiast kopiować do jakiegoś_tam_folderu_z_prawami, dodawać ten folder na chwilę w liście repozytoriów, i instalować Synapticem, po prostu odpalam plik np. psi_cherry_x.x.xx.x.deb wprost z pulpitu dwuklikiem. Gdebi zadba o sprawdzenie zależności oraz o dodanie do lokalnej bazy tak, by plik z pulpitu można było usunąć a Synaptic czy Aptitude dysponowały odpowiednią wiedzą, co usunąć, jeśli mi się znudzi. I o to mi chodziło, gdy wychwalałem "fantastyczną obsługę plików *.deb".

Sorry za zbędne elementy "kodu", ale Markdown mimo, iż powinien elementy sterujące escapować backslashem, nie robi tego, backslash traktując jak każdą zwykłą literę.

Marsjanin: Synaptic, apt-get, aptitude, gdebi, PackageKit i co tam jeszcze można sobie wymyślić koniec końców i tak uruchamiają dpkg. Wszystkie korzystają z jego bazy i dzięki temu jak zainstalujesz w jednym, to możesz zaktualizować (albo usunąć) drugim.

W sumie fakt, że gdebi skutecznie przejmuje rolę lokalnego repozytorium (przynajmniej dla większości użytkowników, którzy spoza oficjalnych repozytoriów będą potrzebowali w porywach kilku pakietów). Po prostu przed 2006 rokiem w debianowatych nie istniał żaden sposób na zainstalowanie lokalnych pakietów z automatycznym spełnieniem zależności (dpkg tego nie potrafi) — trzeba było sobie robić lokalne repo. Nie wiem jak sprawa wygląda w dystrybucjach używających innych menedżerów pakietów. Zresztą, z tego co widzę, Ubuntu wycofuje się ze swojego gdebi na rzecz swojego software-managera.

Istnienie deborphana dowodzi co najwyżej, że Synaptic/apt-get są do dupy. Wieść gminna niesie, że aptitude znacznie lepiej niż apt-get radzi sobie z usuwaniem zależności pakietu przy jego usuwaniu. Z tego co pamiętam aptitude z odpowiednio wymyślnym przełącznikiem wyszukiwania potrafi też znaleźć te same pakiety co deborphan.

umowy na redystrybucję często nawet nie ma kto podpisać
(np. za takim Debianem nie stoi żadna instytucja o osobowości prawnej

Za nim akurat stoi, założona przez Debiana Software in the Public Interest. Ale nadal jest to aktualne dla wielu dystrybucji.

Co do zarzutów z pierwszych komentarzy dotyczących Gentoo/FreeBSD/... — spójrzmy na zagadnienie z punktu widzenia nie kompilacji, a narzędzia służącego do instalacji oprogramowania — należy właśnie jego używać, nie zaś robić to ręcznie. W Gentoo wszystko się kompiluje? A niech się kompiluje jeśli komuś taka wola, ale należy robić to za pomocą emerge, nie z palca.

A ja sądzę, że podstawą jest wiedzieć, co dana forma instalacji niesie za sobą, gdzie grzebie, i tak dalej. Bo szczerze powiedziawszy, niektórzy piszą progsy pod Linuksa jak pod Windows (vide nieszczęsny Tlen) i... bywa, że te programy są dobre. Znak czasów. Pewnie, można się uprzeć i nie korzystać, bo "programista się nie zna". Ale, jemu działa, działa i nam, więc co - dla dobra idei? Eeetam, mi już zapał opadł. Tlen się instaluje w /opt/tlen i mi to nie przeszkadza...

azhag: z pewnością historię i strukturę Debiana znasz znacznie lepiej ode mnie. Ja się opierałem na dwóch akapitach z angielskiej Wikipedii, głównie na zdaniu „Thus, the Debian Project is an independent decentralized organization; it is not backed by a company like Linux distributions such as Ubuntu, openSUSE, Fedora, and Mandriva”. Chociaż może być, że trochę zbyt daleko idący wniosek wyprowadziłem.

Marsjanin: tekst jest przewidziany dla początkujących i ma za zadanie pomóc w wyrobieniu pewnych dobrych nawyków. Bardziej zaawansowani użytkownicy zdają sobie sprawę, że nie można tego traktować dogmatycznie i istnieją uzasadnione przypadki, gdy instalacja spoza repozytorium jest dopuszczalna.

Ja się opierałem na dwóch akapitach z angielskiej Wikipedii,
głównie na zdaniu „Thus, the Debian Project is an independent
decentralized organization; it is not backed by a company (...)”

To, że za Debianem nie stoi firma, nie znaczy, że nie ma on żadnej osobowości prawnej.

@Marsjanin: zejdź łaskawie z kompilowania pod Gentoo, otóż tam nie ma paczek tylko są ebuildy, które zawierają instrukcję jak zainstalować dany program. W skład takiej instrukcji wchodzi na przykład: miejsce skąd można pobrać źródła/binarki(!), sposób instalacji - czyli polecenia służące np. do skompilowania programu, ale nie koniecznie - mogą być to polecenia służące do rozpakowania archiwum i zainstalowania binarki, albo cokolwiek innego. Na przykład wspomniany skype, ale nie tylko. Ba! Są nawet specjalne flagi w konfiguracji określające na jakie licencje oprogramowania się zgadzamy, a jakich nie chcemy widzieć na oczy. Poza tym - nic nie stoi na przeszkodzie, aby dodać własne ebuildy. Jest to przewidziane i udokumentowane (dokumentacja do Gentoo jest naprawdę super). Wspomniałem, że wszystko, włącznie z zarządzaniem zależnościami dzieje się w pełni automagicznie?

W portage zdarzają się też ebuildy do komercyjnych programów. Często w takim wypadku oczekują po prostu, że dane z programem należy we własnym zakresie dostarczyć do odpowiedniego katalogu (na przykład skopiować z płyty dostarczonej przez producenta) więc to nie tak, że się nie da.

Jeżeli zdarzy się, że czegoś nie ma w portage, to zamiast ręcznie kompilować użyszkodnik Gentoo pisze własnego ebuilda i dodaje go do lokalnego repo, a czasem, jak jest wyjątkowo miły udostępnia innym. I tak powinno być.
I myślę, że to samo powinno dotyczyć dowolnej dystrybucji - jeżeli nie ma gotowej paczki należy ją stworzyć a nie marudzić jakie to życie jest chujowe, bo programista był leniem i zlał dodanie swojego programu do repozytorium. To nie jest takie trudne zadanie.

Poniższy formularz służy do wysyłania komentarzy. O ich strukturę i prezentację dba Markdown.

Komentarze stanowią wyłączną własność autorów, choćby zaznaczono inaczej. Również autorom przysługuje wyłączne prawo do ich modyfikacji.

Autor zastrzega sobie prawo do moderacji komentarzy.

Śledzenie wątku: