Ogólnie systemy FOSS, a w szczególności Fedora, są zorganizowane wsadowo. W ten sam sposób wszelkie dodatkowe programy dla nich stworzone przez niezależnych programistów są dystrybuowane w formie pakietów. Dlatego jednym z ważnych zadań użytkownika jest integracja pakietów z jego systemem. Pakiety dla Fedory są dystrybuowane w formacie RPM.
Wynalezienie formatu pakietu RPM i odpowiedniego narzędzia do zarządzania nimi wywarło bardzo duży wpływ na ogólną dystrybucję Linuksa. Dlatego musisz poświęcić mu trochę uwagi.
Format pakietu RPM (który wówczas oznaczał Red Hat Package Manager) i narzędzie o tej samej nazwie do manipulowania takimi pakietami, zdolne do śledzenia zależności i zgłaszania ich naruszeń, odegrały bardzo dużą rolę w zapoznaniu ogółu społeczeństwa z Linuksem. To prawda, że to narzędzie nie wiedziało, jak rozwiązać zależności i nie nauczyło się do dziś: zadanie to rozwiązują bardziej „zaawansowane” narzędzia do zarządzania pakietami. Jednak w porównaniu z cichymi narzędziami pakietowymi Slackware, które w ogóle nie śledziły zależności, była to duża poprawa z punktu widzenia zwykłych użytkowników.
Geneza systemu RPM (rozumiemy przez to zarówno zestaw narzędzi, jak i format pakietów, z którymi współpracują) ginie w ciemności wieków. Pierwsze wersje Red Hata korzystały z systemu RPP, który umożliwiał instalację pakietów za pomocą jednego polecenia, zapytanie o informacje na ich temat i sprawdzenie zależności. Jednakże składanie dla niej pakietów wymagało znacznych modyfikacji źródeł autora, co było stresujące dla opiekunów dystrybucji.
Równolegle z wczesnym Red Hatem przez jakiś czas rozwijała się dystrybucja Bogus, obecnie mało znana wielu osobom. Posiadał własny system pakietów - PMS (Package Management System), napisany przez Rikarda E. Faitha. Miał słaby mechanizm odpytywania informacji o pakietach i po prostu nie było sprawdzania ich zależności. Ale pakiety dla PMS można było skompilować bezpośrednio ze źródeł autora, bez żadnych modyfikacji.
Podczas przygotowań do drugiego wydania Red Hata Rickard Veit wraz z Dougiem Hoffmanem w ramach kontraktu z Red Hatem napisali system PM (Package Management), który zawierał najlepsze cechy RPP i PMS. Choć praktycznie nigdy nie był używany, służył jako jeden z fundamentów RPM.
Sam system RPM został stworzony przez Marka Ewinga (jednego ze współzałożycieli firmy) i Erika Troana, którzy bazowali na wszystkich osiągnięciach swoich poprzedników - twórców RPP, PMS i PM. Jego wersja, przygotowana dla wersji testowych drugiego wydania, została napisana w Perlu ze względu na szybkość, co stwarzało szereg problemów, na przykład przy ładowaniu z dyskietki (a w tamtych czasach był to dość powszechny sposób uruchomić Linuksa). Tuż przed wydaniem Red Hat 2.0 system został całkowicie przepisany w języku C, baza danych pakietów została przeprojektowana w celu zwiększenia niezawodności i wydajności, a także utworzono bibliotekę RPGlib w celu wykorzystania funkcjonalności RPM przez zewnętrznych programistów. Innymi słowy, system RPM uzyskał niemal formę, w jakiej znamy go dzisiaj, podlegając od tego czasu jedynie korekcie błędów i kosmetycznym ulepszeniom.
System RPM (czyli format i użyteczność), stając się standardem i publicznie dostępny w wydaniu Red Hat 2.0, wydanym we wrześniu 1995 roku, od razu zyskał popularność poza systemem macierzystym. Wkrótce zostały one użyte w Caldera Linux (później nazwanym OpenLinux), który początkowo był dokładnym klonem Red Hata. Następnie dystrybucja Suse (genetycznie będąca potomkiem Slackware) przeszła na pakowanie w formacie RPM. Oczywiście wszystkie kolejne klony i pochodne Red Hata, takie jak Mandrake, również korzystały z RPM.
Jako naoczny świadek mogę zaświadczyć, że na przełomie lat 1996–1997 (czas moich pierwszych eksperymentów z Linuksem) system RPM był powszechny, uważany za stabilny i używany daleko poza granicami natywnej dystrybucji.
W ciągu swojego długiego życia format RPM ulegał różnym zmianom, ale w swojej ogólnej linii zachował do dnia dzisiejszego zarówno swoje charakterystyczne cechy, jak i kompatybilność wsteczną. Jego aktualna wersja spośród oficjalnie wspieranych przez projekt o tej samej nazwie w tej chwili (01.02.2011) to 4.8.1. Jest używany w niezliczonych dystrybucjach, reprezentujących zarówno bezpośrednie klony Red Hata (CentOS, Scientific Linux, Oracle Enterprise Linux), jak i jego pochodne, nawet jeśli odeszły od przodka, jak Mandriva czy Altlinux. Poza tym widać to nawet w niektórych układach, które nie są z nim genetycznie spokrewnione (np. we wszystkich wariantach Suse).
Równolegle z ogólną wersją programuRPP, rozwijana jest również jego zaktualizowana wersja, znana jakoRPM5. Został stworzony przez Jeffa Johnsona, który wcześniej był jednym z głównych twórców „zwykłego” RPG. Według niego nowa wersja jest znacznie poprawiona w stosunku do swojego przodka, za który jednak trzeba było zapłacić za brak kompatybilności między tymi dwoma formatami. Dlatego też pakiet RPM5 nie jest oficjalnie wspierany ani przez projekt RPM, ani przez żadną popularną dystrybucję opartą na RPM. Jest on, o ile wiem, używany wyłącznie w dystrybucji PLD i zgodnie z zapowiedzią będzie używany w wydaniu Mandriva 2011.1
Pomimo tego, że wymienione dystrybucje oparte na RPM (i wiele innych nie wymienionych) teoretycznie korzystają z tego samego formatu pakietu, w rzeczywistości szczegóły ich konstrukcji różnią się. Jest to szczególnie prawdziwe w przypadku pakietów źródłowych (które zostaną omówione osobno). Jednakże na tych stronach ograniczę się do rozważenia pakietów RPM dla dystrybucji Fedory. To prawda, że to, co o nich powiedziano, będzie dotyczyło również RHEL, CentOS, Scientific Linux, Oracle Enterprise Linux, ASPLinux.
W ramach dystrybucji Fedory można znaleźć różne rodzaje pakietów o interesującym nas formacie.
Po pierwsze, rozróżnia się binarne pakiety RPM i te same, ale z kodami źródłowymi. Jak sama nazwa wskazuje, te pierwsze zawierają prekompilowane komponenty pakietu dystrybucyjnego, takie jak:
Pakiety źródłowe zawierają swoje tarballe, łatki niezbędne do dostosowania autorskich pakietów do systemu docelowego oraz różnego rodzaju informacje serwisowe.
Bardzo łatwo rozpoznać oba po nazwach, utworzonych według pewnych zasad, które rozważymy na przykładzie najbardziej orientacyjnego pakietu - samego pakietu RPM
Nazwy binarnych pakietów RPM tworzone są według następującego schematu:
Rpm-4.8.1-6.fc14.x86_64.rpm
gdzie rpm to nazwa pakietu, 4.8.1 to numer gałęzi, wersji i konkretnego wydania pakietu, 6 to numer kompilacji bieżącej wersji tej dystrybucji, fc14 to nazwa i jej wersja (która to w tym przykładzie Fedora w wersji 14), x86_64 - architektura, dla której pakiet został złożony.
Nazwa pakietu źródłowego będzie wyglądać mniej więcej tak:
Rpm-4.7.1-6.fc12.src.rpm
Widać, że jedyną różnicą jest dodatkowy przyrostek src, symbolizujący, że mamy do czynienia z pakietem źródłowym, a nie z prekompilowanym plikiem binarnym. I oczywiste jest, że koncepcja architektury kodów źródłowych nie ma sensu - należy je (teoretycznie) skompilować pod którykolwiek z nich.
Wśród pakietów binarnych można znaleźć także takie, które nie są powiązane z żadną architekturą - są one oznaczone dodatkowym przyrostkiem noarch. Należą do nich skrypty w językach interpretowanych, takich jak Perl, Python itp., pakiety czcionek, dokumentacja i tak dalej. Na przykład tak będzie wyglądał pakiet dla jednej z rodzin czcionek Dejavu:
Dejavu-sans-fonts-2.30-2.fc12.noarch.rpm
Wspomniano już powyżej, że binarne pakiety RPM mogą zawierać biblioteki funkcji niezbędnych do ich funkcjonowania. Jest to jednak raczej wyjątek: podobnie jak w przypadku wszystkich systemów typu UNIX, w dystrybucjach opartych na pakietach RPM istnieje tendencja do kompilowania bibliotek jako oddzielnych pakietów. Ponadto każda biblioteka jest zwykle prezentowana w formie dwóch pakietów.
Pierwszy pakiet zawiera rzeczywisty kod funkcji bibliotecznych potrzebnych w każdym przypadku; na przykład pakiet RPM jest dostarczany przez pakiet biblioteczny
Rpm-libs-4.7.1-6.fc12.x86_64.rpm
Drugi pakiet zawiera pliki nagłówkowe, które są niezbędne jedynie przy samodzielnym składaniu pakietów - na co dzień można się bez nich obejść:
Rpm-devel-4.7.1-6.fc12.x86_64.rpm
Po omówieniu nazewnictwa pakietów RPM możemy przejść do kwestii ich wewnętrznej struktury – czyli samego formatu.
Pakiet binarny RPM zawiera dwa komponenty. Z jednej strony jest to zestaw skompilowanych plików, takich jak pliki wykonywalne i biblioteki, wraz z niezbędnymi konfiguracjami, dokumentacją itp., gotowy do włączenia do systemowej hierarchii plików.
Z drugiej strony pakiet zawiera metainformację – opis sporządzony według określonych zasad. Zawiera nazwę pakietu, numer wersji i kompilacji, informacje o deweloperze i jego witrynie głównej, listę plików, ich pozycję w hierarchii plików oraz listę zależności. W razie potrzeby mogą się tu znajdować skrypty instalacyjne i konfiguracyjne. Wszystko to razem pozwala kontrolować integralność pakietu, śledzić zależności, upewnić się, że sama procedura instalacji została zakończona, a także „na czysto” usunąć pakiety.
Komponenty pakietu RPM są spakowane w archiwum cpio - jednego z najstarszych skompresowanych narzędzi do archiwizacji w systemie UNIX. Wcześniej, aż do wersji Fedory 11 włącznie, robiono to za pomocą narzędzia gzip. Począwszy od wersji 12 Fedory, pakiety RPM są kompresowane przy użyciu algorytmu LZMA, który zapewnia znacznie wyższy stopień kompresji - aczkolwiek kosztem czasu poświęconego na to. Co jednak nie sprawi użytkownikowi żadnych niedogodności – gdyż pliki lzma rozpakowywane są paradoksalnie z niemal taką samą szybkością jak gzip. Ale pobieranie ich odbywa się oczywiście znacznie szybciej, co nie może nie zadowolić właścicieli „grubych” i tanich kanałów: w tych warunkach instalowanie pakietów przez Internet jest szybsze niż z lokalnych mediów.
Wróćmy jednak do tego, co znajduje się w pakiecie RPM. Aby to zrobić, najpierw rozpakuj pakiet za pomocą dowolnego standardowego narzędzia (na przykład rpm2cpio lub narzędzia obr./min2tgz) i zobacz, co się stanie:
$ ls obr/min-4.7.1-6/bin/etc/usr/var/
Oznacza to, że widzimy te komponenty pakietu, które zostaną włączone do hierarchii plików systemu docelowego.
Najprostszym sposobem na wprowadzenie drugiego komponentu jest Midnight Commander. Według klucza F3(pakiet RPM jest nadal uważany za przykład) wyświetli wszystkie metainformacje w formie podsumowania. Najpierw będzie to formalny opis pakietu:
Nazwa: obr/min Relokacje: (nie można ich przenieść) Wersja: 4.8.1 Dostawca: Wydanie projektu Fedora: 5.fc14 Data kompilacji: wto 10 sierpnia 2010 11:43:21 Data instalacji: (nie zainstalowano) Host kompilacji: x86-12.phx2 .fedoraproject.org Grupa: Środowisko systemowe/Źródło podstawowe RPM: obr./min-4.8.1-5.fc14.src.rpm Rozmiar: 2035701 Licencja: GPLv2+ Podpis: RSA/SHA256, środa 11 sierpnia 2010 05:58:10, identyfikator klucza 421caddb97a1071f Programista pakujący: Adres URL projektu Fedora: http://www.rpm.org/ Podsumowanie: System zarządzania pakietami RPM Opis: Menedżer pakietów RPM (RPM) to potężny system zarządzania pakietami obsługiwany z wiersza poleceń, umożliwiający instalowanie, deinstalowanie, weryfikowanie, wysyłanie zapytań i aktualizowanie pakietów oprogramowania. Każdy pakiet oprogramowania składa się z archiwum plików wraz z informacjami o pakiecie, takimi jak jego wersja, opis itp.
Znaczenie wszystkich pól jest intuicyjne. Proszę tylko o zwrócenie uwagi na pole Grupa: będziemy musieli pamiętać o przynależności grupowej pakietu, jeśli chodzi o zarządzanie pakietami za pomocą systemu yum.
Następnie pojawi się skrypt instalacyjny:
Skryptlet Posttrans (przy użyciu /bin/sh): # XXX to jest niezgrabne i brzydkie, sam RPM powinien obsłużyć to dbstat=/usr/lib/rpm/rpmdb_stat if [ -x "$dbstat" ]; to jeśli "$dbstat" -e -h /var/lib/rpm 2>&1 | grep -q „nie” pasuje do wersji środowiska | Nieprawidłowy argument”; następnie rm -f /var/lib/rpm/__db.* fi fi wyjście 0
Rwxr-xr-x 1 korzeń korzeń 20392 10 sierpnia 11:42 /bin/rpm drwxr-xr-x 2 korzeń korzeń 0 10 sierpnia 11:42 /etc/rpm -rwxr-xr-x 1 korzeń korzeń 7424 10 sierpnia 11: 42 /usr/bin/rpm2cpio...
Następnie pliki biblioteki:
Rw-r--r-- 1 root root 40537 10 sierpnia 11:42 /usr/lib/rpm/macros drwxr-xr-x 2 root root 0 10 sierpnia 11:42 /usr/lib/rpm/platforma drwxr-xr -x 2 root root 0 10 sierpnia 11:42 /usr/lib/rpm/platform/amd64-linux ...
Rw-r--r-- 1 root root 44206 7 grudnia 2009 /usr/share/doc/rpm-4.8.1/COPYING -rw-r--r-- 1 root root 639 7 grudnia 2009 /usr/share/ doc/rpm-4.8.1/CREDITS -rw-r--r-- 1 root root 496233 11 czerwca 2010 /usr/share/doc/rpm-4.8.1/ChangeLog.bz2 -rw-r--r-- 1 root root 656 7 grudnia 2009 /usr/share/doc/rpm-4.8.1/GROUPS ...
I na koniec pliki zmienne:
Drwxr-xr-x 2 root root 0 10 sierpnia 11:42 /var/lib/rpm -rw-r--r-- 1 root root 0 10 sierpnia 11:42 /var/lib/rpm/Basenames -rw-r --r-- 1 root root 0 10 sierpnia 11:42 /var/lib/rpm/Confusedname -rw-r--r-- 1 root root 0 10 sierpnia 11:42 /var/lib/rpm/Dirnames .. .
Wszystkie te informacje można wyświetlić w częściach - ustawiając kursor na pliku w Midnight Commanderze
Rpm-4.7.1-6.fc12.x86_64.rpm
i naciśnięcie Wchodzić.
Teraz zobaczymy listę plików „metainformacyjnych” zawartych w pakiecie:
/.. │-TOP-│gru 16 12:04 /INFO │ 0│wrz 21 00:00│ CONTENTS.cpio │ 0│wrz 21 00:00 HEADER │ 1185│wrz 21 00:00 *INSTALL │ 39│wrz 21 00:00 *AKTUALIZACJA │ 39│Wrz 21 00:00
Zawartość plików łatwo odgadnąć. Zatem CONTENTS.cpio to pełna lista wszystkich plików i ścieżek do nich:
Rwxr-xr-x 1 korzeń root 20808 21 września 17:30 ./bin/rpm drwxr-xr-x 2 root root 0 21 września 17:30 ./etc/rpm ...
i tak dalej. Plik HEADER zawiera ten sam opis, który właśnie przejrzeliśmy F3, *INSTALL i *UPGRADE – skrypty wykonywalne służące do odpowiedniego celu. Natomiast w katalogu /INFO znajduje się wiele małych plików, z których ostatecznie zbierane są podsumowujące metainformacje. Spośród nich skupię się tylko na REQUIRENAME - jest to znana lista zależności, która dla pakietu RPM wygląda mniej więcej tak:
/bin/bash /bin/sh /bin/sh config(rpm) = 4.8.1-5.fc14 coreutils curl db4-utils libacl.so.1())(64bit) ...
W rzeczywistości pakiet RPM nie zawiera w sobie żadnej hierarchii plików. A to, że nam się tak ukazuje, to wyłącznie zasługa Midnight Commandera, który przywraca go do stanu, w jakim był przed montażem.
Baza pakietów RPM jest komponentem niezbędnym do funkcjonowania systemu: zapewnia możliwość pozyskiwania informacji o pakietach, ich aktualizacji oraz usuwania. Jest tworzony podczas instalacji systemu w katalogu /var/lib/rpm i zmienia się przy każdej operacji na pakietach.
Baza danych pakietów RPM korzysta z Berkeley DB, starożytnego (rok butelkowania 1986), prostego (nierelacyjnego) DBMS, ale szybkiego, wydajnego i dlatego powszechnie używanego do dziś.
Pliki bazy danych RPM są binarne i nawet magia „nocnego dowódcy” nie pozwoli dojrzeć w nich niczego zrozumiałego. Pozostaje więc wierzyć na słowo autorom dokumentacji, że
Baza pakietów RPM jest niezbędna do normalnego funkcjonowania tego systemu - jej uszkodzenie pociąga za sobą nieprzyjemne konsekwencje, dlatego też istnieją sposoby na przywrócenie jego integralności w sytuacjach awaryjnych, co rozważymy z czasem.
Po ogólnym zapoznaniu się ze strukturą pakietów RPM, zobaczmy, co można z nimi zrobić. Zacznijmy od narzędzia o tej samej nazwie, przeznaczonego do pracy z pojedynczymi pakietami. W starożytności było to błogosławieństwo i przekleństwo dla początkujących użytkowników dystrybucji Red Hat, jej klonów i pochodnych.
Jak już wspomniano, narzędzie RPM stało się błogosławieństwem dla użytkowników dystrybucji Red Hat i wszystkich jej następców. Ponieważ uwolniło to je od konieczności niezależnej kompilacji: prawie wszyscy programiści, którzy nie gardzili dystrybucją swoich pakietów w formie binarnej, montowali je w formacie RPM, a usługi takie jak http://rpmfind.net ułatwiły ich znalezienie w Internecie . Pamiętam, że w tamtych latach w obiegu obowiązywała następująca maksyma życiowa:
za pomocą RPM i Internetu każdy zestaw dystrybucyjny można w ciągu jednego dnia przekształcić w braci bliźniaków
Jednak okazało się to również przekleństwem dla użytkowników, zwłaszcza początkujących: śledząc zależności pakietów podczas instalacji i usuwania, narzędzie RPM w ogóle ich nie rozwiązało, a jedynie zgłosiło wykrycie wywrotki i to w dość niezrozumiałej formie dla początkującego.
Te czasy odeszły w zapomnienie: nastała era repozytoriów pakietów i narzędzi do pracy z nimi, takich jak apt-rpm, urpmi i wreszcie yum – główny bohater kolejnej serii notatek. Które zajmują się rutynową manipulacją pakietami. Jednak narzędzie RPM nadal pozostaje najprostszym narzędziem do operacji na pojedynczych pakietach, zwłaszcza tych, których nie ma w oficjalnych repozytoriach. A w niektórych przypadkach - na przykład podczas podłączania repozytoriów stron trzecich - może być prawie niezastąpiony.
Poświęćmy więc trochę czasu na poznanie jego podstawowych funkcji, na które jest najbardziej potrzebne w życiu codziennym. To tylko krótkie podsumowanie praktycznego zastosowania. Ponadto jest skierowany do osób, które nie miały wcześniej styczności z systemami opartymi na obrotach. Ci, którzy będą krzyczeć z publiczności - podaj mi szczegóły, wyślę je wcześniej cioci Many, ona ci wszystko powie.
Narzędzie RPM, podobnie jak dpkg w dystrybucjach opartych na Debie, jest tylko jednym z przedstawicieli całej rodziny, opracowanym wraz z formatem o tej samej nazwie w ramach niezależnego projektu.
Wśród dodatkowych narzędzi warto wymienićrpm-build - narzędzie do tworzenia własnych pakietów oraz RPG2html - narzędzie do wydobywania metainformacji z pakietów i prezentowania ich w ludzkiej postaci (znajduje się tam pełna lista całej rodziny). Jednak na początku tej serii stron porozmawiamy tylko o samych obrotach.
Istnieje pięć głównych trybów korzystania z narzędzia RPM:
Istnieje również tryb budowania pakietów, ale na razie nie będziemy o tym rozmawiać.
Każdy tryb odpowiada jednej z podstawowych opcji polecenia obr./min. Mogą im towarzyszyć dodatkowe opcje, specyficzne lub wspólne dla wszystkich trybów. Pierwszy z nich zostanie uwzględniony przy opisywaniu trybów. Wśród tych ostatnich najbardziej poszukiwane są:
Istnieje również kilka opcji „poza trybem”, w szczególności do przywracania bazy danych pakietów.
Argumentem polecenia obr/min jest zwykle nazwa pliku pakietu; często takich argumentów może być kilka (w limicie - tyle, ile chcesz). W niektórych przypadkach wystarczy podanie krótkiej nazwy pakietu - na przykład dla naszego stałego przykładu po prosturpm. W innych sytuacjach wymagana jest pełna nazwa, wskazująca numer wersji, kompilację, dystrybucję, architekturę - na przykład obr/min-4.8.1-5.fc14.x86_64.rpm. A jeśli pliku pakietu nie ma w bieżącym katalogu, będziesz musiał poprzedzić go pełną ścieżką do niego, powiedzmy /var/cache/akmods/ .
... służy do uzyskania informacji o pakiecie, w szczególności o jego statusie (czy jest zainstalowany w systemie). Główną opcją zapytania jest -q (lub --query), która w odpowiedzi wyświetli pełną nazwę pakietu:
obr/min -q obr/min obr/min-4.8.1-5.fc14.x86_64
Należy pamiętać, że jako argument opcji request wystarczy krótka nazwa pakietu, a samo polecenie można wydać w imieniu zwykłego użytkownika.
Dodatkowe opcje zależą od celu żądania. W ten sposób obecność paczki w systemie sprawdzana jest za pomocą polecenia:
$ obr/min -qa nazwa pakietu
gdzie dodatkowa opcja -a (lub --all) określa żądanie do wszystkich pakietów dostępnych w bazie danych. Jeśli pakiet jest zainstalowany, odpowiedzią na to polecenie będzie
$ obr/min -qa opera opera-10.00-4440.gcc4.shared.qt3.x86_64
Jeśli nie, zostanie zwrócony wiersz poleceń.
Formalny opis pakietu można uzyskać za pomocą polecenia
$ obr/min -qi obr/min
odpowiedź na które brzmiałoby:
Nazwa: obr/min Relokacje: (nie można przenieść) Wersja: 4.8.1 Dostawca: Wydanie projektu Fedora: 5.fc14 Data kompilacji: wto 10 sierpnia 2010 11:43:21 Data instalacji: niedziela 31 października 2010 10:28:06 Host kompilacji: x86-12.phx2.fedoraproject.org Grupa: Środowisko systemowe/Źródło podstawowe RPM: obr./min-4.8.1-5.fc14.src.rpm Rozmiar: 2035701 Licencja: GPLv2+ Podpis: RSA/SHA256, środa 11 sierpnia 2010 05:58 :10, identyfikator klucza 421caddb97a1071f Osoba pakująca: Adres URL projektu Fedora: http://www.rpm.org/ Podsumowanie: System zarządzania pakietami RPM Opis: Menedżer pakietów RPM (RPM) to potężny system zarządzania pakietami oparty na wierszu poleceń, który można zainstalować , odinstalowywanie, sprawdzanie, wysyłanie zapytań i aktualizowanie pakietów oprogramowania. Każdy pakiet oprogramowania składa się z archiwum plików wraz z informacjami o pakiecie, takimi jak jego wersja, opis itp.
Łatwo zauważyć, że jest to ta sama część nagłówka (HEADER), którą poprzednio oglądaliśmy w Midnight Commanderze.
Dodatkowa opcja l pozwoli nam wyodrębnić zawartość CONTENTS.cpio:
$ obr/min -ql obr/min /bin/rpm /etc/rpm /usr/bin/rpm2cpio /usr/bin/rpmdb /usr/bin/rpmquery /usr/bin/rpmsign /usr/bin/rpmverify ...
Powyższa dyskusja dotyczyła uzyskania informacji o zainstalowanym pakiecie. Dużo ciekawsze jest jednak uzyskanie informacji o pakiecie, który nie jest zainstalowany - aby określić, czy jest on potrzebny w naszej działalności, czy też nie. A jest to możliwe - dodając dodatkową opcję p do -qi i podając pełną nazwę pakietu oraz ścieżkę do niego. A ponieważ odinstalowany pakiet najprawdopodobniej znajduje się w jakimś źródle sieciowym, jako ścieżka pojawi się adres URL, na przykład:
$ obr/min -qip http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/joe-3.7-5.fc13.x86_64.rpm
Który wyświetli dokładnie te same informacje, co przy zapytaniu o pakiet lokalny:
Imię i nazwisko: joe Relokacje: (nie można go przenieść) Wersja: 3.7 Dostawca: Wydanie projektu Fedora: 5.fc13 Data kompilacji: środa 10 lutego 2010 09:57:06 Data instalacji: (nie zainstalowano) Host kompilacji: x86-03.phx2.fedoraproject Grupa .org: Applications/Editors Źródło RPM: joe-3.7-5.fc13.src.rpm Rozmiar: 1177186 Licencja: GPLv2+ Podpis: RSA/SHA256, środa 28 lipca 2010 21:59:42, identyfikator klucza 421caddb97a1071f Osoba pakująca: Projekt Fedora URL: http://sourceforge.net/projects/joe-editor/ Podsumowanie: Łatwy w użyciu, niemodalny edytor tekstu Opis: Joe to potężny, łatwy w użyciu, niemodalny edytor tekstu. Wykorzystuje te same skróty klawiaturowe WordStar, które są używane w środowisku programistycznym firmy Borland.
Dodatkowa opcja f pozwala określić nazwę pakietu będącego właścicielem określonego pliku:
$ obr/min -qf /usr/lib/rpm/rpm2cpio.sh obr/min-4.8.1-5.fc14.x86_64
W trybie zapytania dostępnych jest znacznie więcej opcji, które w razie potrzeby można znaleźć na stronie podręcznika pakietu RPM.
...zapewnia weryfikację integralności zainstalowanego pakietu. Odbywa się to poprzez porównanie jego plików z ich odpowiednikami z oryginalnego pakietu według parametrów takich jak typ, rozmiar, suma kontrolna (MD5), własność i atrybuty dostępu. Główną opcją dla tego trybu jest -V; bez dodatkowych opcji, podając nazwę pakietu, sprawdza poprawną lokalizację swoich plików w hierarchii plików.
Jeśli sprawdzenie zakończy się pomyślnie, to znaczy, że zainstalowane i oryginalne pliki są całkowicie identyczne, nie zostaną wyświetlone żadne komunikaty – zostanie zwrócony jedynie monit wiersza poleceń. Jeśli w jakimkolwiek parametrze wystąpią między nimi rozbieżności, zostanie to wyświetlone w formie symbolicznej. Niedopasowania są sygnalizowane w następujący sposób:
Pasujące parametry są oznaczone pojedynczą kropką. Niestety, nie mogę podać przykładów - bez względu na to, w który pakiet wchodzę, aby sprawdzić, wszystko okazuje się w porządku. Ale nie chcę tego celowo zepsuć.
Poza tym wynik jakiegokolwiek komunikatu nie zawsze oznacza, że coś jest nie tak z zainstalowanym pakietem. Na przykład, jeśli spróbujemy zweryfikować pakiet obr./min naszego modelu za pomocą polecenia
$ obr/min -V obr/min
na wyjściu zobaczymy:
Prelink: /bin/rpm: co najmniej jedna z zależności pliku uległa zmianie od czasu wstępnego dowiązania S.?...... /bin/rpm prelink: /usr/bin/rpm2cpio: co najmniej jedna z zależności pliku została zmieniona zmienione od czasu wstępnego dowiązania S.?...... /usr/bin/rpm2cpio
Oznacza to po prostu, że pliki wykonywalne pakietu RPM, po jego instalacji, przeszły wstępną procedurę linkowania (prelink - opowiem Ci, co to jest w odpowiednim czasie). W rezultacie oczywiście stracili tożsamość ze swoimi imiennikami z oryginalnego opakowania.
Dodatkowe opcje trybu skanowania pozwalają zweryfikować konkretny plik:
$ obr/min -Vf /usr/bin/rpm2cpio
porównaj zainstalowany pakiet z oryginalnym pakietem RPM:
$ obr/min -Vp ścieżka2/pełna nazwa_pakietu
a także wykonaj pełne skanowanie wszystkich zainstalowanych pakietów:
# obr./min -Va
Ponieważ wynik ostatniego polecenia będzie bardzo długi, sensowne jest użycie go w urządzeniu do ważenia korzeni z poleceniem takim jak less lub most . Możesz także użyć polecenia grep, aby zidentyfikować tylko pakiety; zawierające rozbieżności z oryginałem według jednego z kryteriów wymienionych powyżej. Na przykład struktura poleceń
# obr./min -Va | grep S
wygeneruje listę pakietów różniących się rozmiarem od oryginałów i potok
# obr./min -Va | grep 5
wykryje różnice w sumach kontrolnych.
Chciałbym zwrócić uwagę na zmianę wyglądu wiersza poleceń przy korzystaniu z dodatkowej opcji a: jeśli poprzednie polecenia weryfikacyjne są zwykle uruchamiane w imieniu zwykłego użytkownika, wówczas lepiej jest przeprowadzić pełną weryfikację wszystkich pakietów z uprawnieniami administratora, ponieważ tylko on ma prawo dostępu do niektórych plików i katalogów systemu.
Oprócz wymienionych, istnieje również wiele opcji weryfikacji podpisów cyfrowych i kluczy publicznych - jak zwykle można je znaleźć na stronie man (8)rpm.
...są ze sobą ściśle powiązane. Ich główne opcje to:
Ważne jest, aby zakres opcji -i i -F był ściśle określony: polecenie określające pierwszą opcję odmówi wykonania, jeśli w systemie jest starsza wersja pakietu o tej samej nazwie. I odwrotnie - polecenie z drugą opcją zwróci komunikat o błędzie, jeśli w systemie nie jest zainstalowana poprzednia wersja. Dlatego najczęściej używana jest opcja ogólna -U. Oczywiście do pomyślnego wykonania poleceń z dowolnej z tych opcji wymagane są uprawnienia administratora.
Argumentami poleceń instalacji i aktualizacji muszą być pełne nazwy plików pakietu, wskazujące lokalną ścieżkę do nich lub adres sieciowy. Ogólnie rzecz biorąc, możesz określić dowolną liczbę argumentów, czyli pakietów do zainstalowania lub aktualizacji. W niektórych przypadkach konieczne jest określenie dwóch argumentów w poleceniu.
Powiedziałem wcześniej, że narzędzie RPM nie tylko instaluje pakiety, ale także sprawdza ich zależności. Choć niestety ich nie rozwiązuje, a jedynie zgłasza naruszenia. Na przykład próba bezpośredniej instalacji kdebase
Rpm -ihv http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/kdebase-4.5.2-2.fc14.x86_64.rpm
wygeneruje długą listę niezaspokojonych zależności:
Pobieranie http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/kdebase-4.5.2-2.fc14.x86_64.rpm błąd: Nieudane zależności: kdebase-libs(x86 -64) = 6:4.5.2-2.fc14 jest potrzebne przez kdebase-6:4.5.2-2.fc14.x86_64
To, jak mówią, jest to codzienna sprawa i jasne jest, jak rozwiązać taką sytuację. Ponieważ instalowanie tak dużych pakietów z tak złożonymi zależnościami bezpośrednio przez RPM jest niewdzięcznym zadaniem, wymyślono do tego inne narzędzia. Na przykład mniam, o czym przekonamy się w swoim czasie.
Są sytuacje bardziej odmienne: pozornie prosty pakiet podczas próby instalacji wymaga innego jako zależności. A ten z kolei odmawia montażu, gdyż odnosi się do braku tego pierwszego. Tak więc właśnie teraz, gdy zacząłem aktualizować jeden z moich eksperymentalnych systemów do wersji „rawhide”, stanąłem przed faktem, że pakiet fedora-release-rawhide-15-0.3.noarch.rpm nie chciał się zainstalować bez fedory -release -15-0.3.noarch.rpm - i odwrotnie.
W takich przypadkach należy określić wszystkie współzależne pakiety jako argumenty jednego polecenia:
# obr/min -ivh http://URL/path2/(fedora-release-15-0.3.noarch.rpm, fedora-release-rawhide-15-0.3.noarch.rpm)
Co więcej, co typowe, kolejność nazw nie odgrywa żadnej roli - jeśli zostaną określone wszystkie współzależne pakiety, to wszystkie zostaną pomyślnie zainstalowane.
W ostatnim poleceniu niespodziewanie i bez ostrzeżenia pojawiły się dwie opcje - v i h . Jednak o tym pierwszym wspomniano już wcześniej – ta dodatkowa opcja all-mode nakazuje wyświetlanie szczegółowych komunikatów o postępie dowolnych zadań. Opcja -h (lub --hash) zapewnia wygodną formę prezentacji tego wyniku.
Oprócz podstawowych opcji instalacji i aktualizacji, opcji dodatkowych jest znacznie więcej, ale za nimi jak zawsze stoi Ciocia Mana.
... często okazuje się nie mniej popularny niż tryby instalacji i aktualizacji. Jednak to zadanie nie jest trudne i ogólnie robi się to w ten sposób:
# obr/min -e nazwapakietu
Podstawowa nazwa pakietu jest tutaj wystarczająca, ale oczywiście wymagane są uprawnienia administratora.
Jeśli podczas usuwania zostaną zerwane zależności, pojawi się komunikat o błędzie:
Błąd: Nieudane zależności:
Oczywiście można to zignorować za pomocą dodatkowej opcji --nodeps. Lub, jeśli masz całkowitą pewność, że masz rację, wpisz w wierszu poleceń usuwania nazwy plików pakietu, które mają zależności powiązane z usuwanym plikiem.
Wszystko to jest jednak obarczone konsekwencjami - dlatego w niejednoznacznych przypadkach lepiej nie używać polecenia obr./min do usuwania plików. Jednakże, jak już wspomniano, mniam istnieje po to, aby użytkownik nie drżał.
Narzędzie RPM przeznaczone jest przede wszystkim do instalowania pojedynczych pakietów z dowolnego źródła - lokalnego lub sieciowego (na przykład z witryn programistów), ale głównie tego pierwszego. System zarządzania pakietami yum skupia się na dostępie do repozytoriów pakietów, głównie sieciowych. Chociaż używanie go z lokalnymi repozytoriami również nie jest zabronione.
Na początek spróbujmy odpowiedzieć na pytanie czym jest repozytorium. Ponieważ jego obecność dzisiaj jest jednym z głównych znaków definiujących dystro.
Przetłumaczone na język rosyjski słowo magazyn oznacza składowanie— i tak właśnie twierdzą puryści językowi (czyli ci, którzy wolą się nazywać gramatyczny nazista). Jednak, jak to zwykle w życiu bywa, ludzie przyjęli dla nich inną nazwę - repozytorium lub, w naszym języku, cyrylicą brazylijską, rzepa. Dlaczego w liczbie mnogiej stanie się jasne w dalszej historii. Cóż, jako synonim wolę to określenie gówno.
Samo repozytorium można bowiem w pierwszym przybliżeniu określić jako miejsce przechowywania specjalnie zebranych dla danej dystrybucji pakietów, do którego możliwy jest swobodny dostęp (mówimy tylko o systemach darmowych).
Jednak dostępność serwera przechowującego pakiety nie wystarczy, aby można było nazwać go repozytorium. Pakiety w repozytorium muszą być zorganizowane według pewnych zasad charakterystycznych dla danej dystrybucji. Ich system przechowywania musi zapewniać ich uzupełnianie, aktualizację i co najważniejsze utrzymanie integralności i spójności pakietów pod względem zależności i dla wszystkich aktualnie obsługiwanych wersji dystrybucji.
Innymi słowy, pakietom w repozytorium muszą towarzyszyć bazy danych - te same, z których korzysta system zarządzania pakietami danej dystrybucji, a także jej system budowania pakietów.
Ponadto wysoce pożądane jest, aby repozytorium było zdublowane na kilku niezależnych serwerach – z oczywistych powodów. To prawda, że nie jest to niezbędny wymóg. Jednak obecność luster jest jednym z powodów używania słowa repozytorium w liczbie mnogiej.
Zobaczmy teraz, jak wszystkie te ogólne rozważania wyglądają w praktyce - w odniesieniu do repozytoriów Fedory.
Fizycznie repozytoria Fedory są zbiorem zagnieżdżonych podkatalogów na serwerach FTP lub http i czasami mają dość złożoną i nie do końca przejrzystą strukturę. Znajomość jej nie jest dla użytkownika konieczna – jednak w szeregu sytuacji awaryjnych nie będzie zbędna. A ponieważ ta konstrukcja nie jest nigdzie opisana, przynajmniej w języku rosyjskim, poświęćmy jej trochę uwagi.
Jednak niecierpliwi czytelnicy mogą od razu przejść do kolejnego rozdziału – poświęconego logicznej strukturze repozytoriów. I do chwili obecnej będzie on tworzony tylko wtedy, gdy zajdzie taka potrzeba.
Główne, że tak powiem, repozytorium pakietów, jak można się domyślić, znajduje się pod adresem i głębiej. Jednak w praktyce użytkownik prawie nigdy tam nie dociera: jak zobaczymy w części dotyczącej zarządzania pakietami, system ten automatycznie wysyła go...
nie, nie tam, gdzie myślałeś o stopniu swojej deprawacji, ale do najszybszego lustra. Co więcej, jest najszybszy fizycznie i precyzyjnie w danym momencie - bo sprawdza to nie przynależność strefowa i inne cechy formalne, ale odpowiedź na faktyczne żądanie. Jeśli oczywiście zainstalowana jest odpowiednia wtyczka dla yum - ale o tym porozmawiamy nieco później.
Zatem wpisując w wierszu przeglądarki coś takiego jak http://download.fedoraproejct.org, nasz radziecki użytkownik trafi na serwer z adresem URL takim jak http://mirror.name_rek.ru/fedora/linux/ (i jest to możliwe, że nawet i wcale nie ru). Nie będę wymawiał nazwy tej nazwy - rzeka - pełną listę możliwych opcji można zobaczyć tutaj http://mirrors.fedoraproject.org/publiclist. A dać pierwszeństwo jednemu z nich oznacza, jak powiedziałby Shurik, okazanie niesprawiedliwości drugiemu nazwa rzeki.
Naturalnie, struktura wszystkich nazwy rzek jest identyczny, więc można to rozważyć na przykładzie dowolnego lustra.
Tak więc, kiedy już znajdziemy się w River_name/fedora/linux/, widzimy następujące katalogi:
Jak można się domyślić, katalog development zawiera pakiety, które są w fazie rozwoju (ważny jest tutaj podkatalog /development/rawhide/, do którego powrócimy w odpowiednim czasie), a katalog update zawiera ostatnio zaktualizowane. Ale katalog wydań jest dokładnie tym, co nas w tej chwili interesuje.
12 13 14
i podkatalog testowy. Czasami jest pusta, zawartość w niej zawarta pojawia się, gdy wersja alfa kolejnego wydania zostanie wydzielona z gałęzi rozwojowej (ta sama surowa skóra).
Kontynuujmy wspinaczkę po drzewie hierarchicznym. W gałęzi wydania widzimy następujące podkatalogi:
Wszystko Fedora na żywo
Pierwsza obejmuje pakiety różnych wersji i zespołów wyprodukowanych w trakcie istnienia wydania. Pierwsza, jak sama nazwa wskazuje, zawiera aktualne aktualizacje kompilacji pakietów, natomiast druga zawiera obrazy LiveCD dla obu obsługiwanych architektur (i686 i x86_64). Obydwa zostaną omówione w odpowiednim czasie. Ale będziemy nadal wspinać się po katalogu Fedory - zwłaszcza, że można go uznać za przykład struktury dowolnego katalogu na serwerach projektu.
Zatem w katalogu fedora/linux/releases/14/Fedora/ możesz zobaczyć następujące podkatalogi:
Źródło I386 x86_64
Drugi z nich zawiera źródłowe pakiety RPM (tzw. *.src.rpm), które również zostaną omówione osobno. Pierwszy i trzeci zawierają podzespoły odpowiednio dla architektur 32- i 64-bitowych. Oczywiście w środku są absolutnie takie same, więc przyjrzyjmy się ich wnętrzu na przykładzie teraz bardziej odpowiedniej architektury x86_64.
Iso jigdo os
Pierwsza zawiera obrazy dysków instalacyjnych - płytę DVD, zestaw płyt CD oraz dysk do instalacji sieciowej (netinst), które zostaną omówione w części dotyczącej instalacji systemu. Drugi zawiera pliki metadanych dla jigdo (Jigsaw Download), systemu dystrybucji dużych plików (w tym przypadku obrazów tych samych dysków instalacyjnych) i służy temu samemu celowi, co poprzedni. Cóż, w trzecim, w podkatalogu Pakiety, faktycznie znajdują się wymagane pakiety.
Dodatkowo w katalogu fedora/linux/releases/14/Fedora/x86_64/os/ widoczne są pliki usług, takie jak klucze GPG do uwierzytelnienia, pliki opisu repozytorium (w podkatalogach repodata i repoview), pliki do budowania własnych obrazy dysków startowych (w podkatalogach obrazów i isolinux), które w tej chwili nas nie interesują.
Jeśli chodzi o zawartość katalogu Packages, jest ona reprezentowana przez pakiety RPM - te, które są bezpośrednio obsługiwane w ramach projektu Fedora.
Repozytorium główne nie wyczerpuje jednak listy pakietów dostępnych w naszej dystrybucji. Istnieje również repozytorium dodatkowych pakietów utrzymywanych przez wolontariuszy w ramach samodzielnego projektu RPMFusion.
Znajduje się rzeczywiste repozytorium dodatkowych pakietów. Widzimy w nim dwa katalogi - wolny i niewolny. Pierwszy przeznaczony jest dla programów całkowicie darmowych (nawiasem mówiąc, w głównym repozytorium Fedory dostępne są tylko takie), drugi dla programów, których dystrybucja podlega pewnym ograniczeniom. Które dokładnie – do tego pytania wrócimy później.
Wewnętrzna struktura obu katalogów jest taka sama. Zawierają podkatalogi el i fedora. Pierwsza obejmuje pakiety przeniesione z RHEL i nie jest teraz dla nas interesujące. Drugi zawiera podkatalogi:
Rozwój/wydania/aktualizacje/
jak również pliki opisu repozytorium.
Przeznaczenie katalogów jest mniej więcej jasne po ich nazwach (do tego zagadnienia wrócimy później), dlatego skupimy się jedynie na katalogu releases. Zawiera podkatalogi dla sześciu najnowszych wydań, w tym takich, które są znacznie bardziej „głębokie” niż te obsługiwane w głównym repozytorium. W każdym z nich zobaczymy pojedynczy podkatalog Wszystko. Zawiera także znane już podkatalogi „architektoniczne”:
Debuguj/os/
Pierwsza, jak można się domyślić, zawiera informacje debugowania, które nie są dla nas teraz interesujące. Ale w drugim - faktyczne pakiety. Zawiera pakiet opisu głównego repozytorium -rpmfusion-free-release. Ten sam, którego instalacja wyraźnie prowadzi do połączenia tej „rzepy”. A w odpowiednim podkatalogu katalogu nonfree podobny pakiet zostanie odpowiednio nazwany -rpmfusion-nonfree-release.
Dla użytkowników oryginalnej Fedory wystarczą wymienione repozytoria w czystej postaci. Jednak dla naszych rosyjskojęzycznych współobywateli, jeśli nie obowiązkowa, to bardziej niż pożądana, znajomość repozytorium russianfedora jest.
Znajduje się on w katalogu o tej samej nazwie pod następującym adresem (o ile wiem, jedynym jak dotąd). A jego struktura jest następująca: na pierwszym poziomie zagnieżdżenia znajdują się podkatalogi
W tej chwili interesuje nas tylko ostatni podkatalog. Zawiera trzy podkatalogi:
Skład wszystkich trzech kategorii zostanie omówiony bardziej szczegółowo w następnej sekcji - na razie interesuje nas tylko fizyczna struktura odpowiednich katalogów.
Jest identycznie: każdy z nich zawiera podkatalogi el/ i fedora/ w tym samym celu co w RPM Fusion. Z kolei w podkatalogu fedora/ znajdują się podkatalogi development/, releases/ i updates/, natomiast w podkatalogu releases/ znajdują się katalogi z numerami głównych (głównych) wydań, obecnie od 10 do 15.
W każdym katalogu wydania widzimy pojedynczy podkatalog Everything/, który zawiera podkatalogi dla obu obsługiwanych architektur – i386/ i x86_64/, a także podkatalog source/ dla pakietów źródłowych. I wreszcie, piętro niżej znajdują się podkatalogi debug/ i os/ o jasnym (czyli takim samym jak w RPM Fusion) przeznaczeniu.
Opisane powyżej repozytoria wystarczą większości użytkowników na niemal każdą okazję. Jednak w wielu przypadkach istnieje potrzeba dodatkowych opakowań, które z tego czy innego powodu nie są uwzględnione w oficjalnych „rzepach” - być może jeszcze nie zostały uwzględnione. Typowym przykładem jest dziś przeglądarka Chromium: nie można jej znaleźć ani w RPM Fusion, ani w rosyjskiej Fedorze.
I tutaj na ratunek przyjdzie przede wszystkim repozytorium Fedora People - jest przeznaczone specjalnie dla pakietów zbieranych przez niezależnych opiekunów. Pod względem treści nie pokrywa się z repozytoriami oficjalnymi i „półoficjalnymi”, jednak z tego, co wiem, jego pakiety są z nimi testowane pod kątem kompatybilności, dzięki czemu można z nich korzystać bez obaw.
Struktura repozytorium Fedora People jest niezwykle prosta: pod podanym adresem zobaczysz wiele katalogów, których nazwy powtarzają nazwy zawartych w nich pakietów. W każdym z nich znajdzie się szereg podkatalogów dla obsługiwanego zakresu wydań – różniących się w zależności od przypadku. Podkatalog każdego wydania zawiera trzy standardowe podkatalogi - i386/, SRPMS/ i x86_64/, zawierające plik opisu repozytorium i rzeczywiste pliki pakietu.
W niektórych przypadkach interesujące może być repozytorium ATrpms. Zawiera liczne pakiety treści multimedialnych, wyspecjalizowane zespoły jądra i obfite sterowniki dla kart graficznych Nvidia (w tym dla starszych modeli, których nie można już znaleźć na oficjalnej stronie firmy). Możesz wyświetlić pełną listę pakietów i listę obsługiwanych wydań.
W artykułach i recenzjach poświęconych Fedorze można znaleźć odniesienia do wielu innych dodatkowych repozytoriów dla tej dystrybucji - ich listę można zobaczyć np. w linkach z tych samych ATrpms. Jednak prawie wszystkie z nich straciły na znaczeniu. Niektórzy (Livna, Freshrpms, Dribble) są teraz zjednoczeni w ramach RPM Fusion. Inne zawierają pakiety dla bardzo starych wersji Fedory. Otóż repozytorium Tigro stało się bazą dla rosyjskiej Fedory - choć samo w sobie przyda się leniwym posiadaczom starszych wersji Fedory.
Fizyczna struktura repozytoriów Fedory, zwłaszcza głównego, wydaje się dość zagmatwana. Na szczęście użytkownik, jak już wspomniano, praktycznie nie musi się z tym zmagać. W 99 przypadkach na 100 wystarczy mu poruszać się po ich logicznej organizacji, którą teraz rozważymy.
Na początek warto powiedzieć, dlaczego słowo „repozytoria” było wcześniej używane w liczbie mnogiej. Aby to zrobić, należy wziąć pod uwagę klasyfikację pakietów przyjętą w tej dystrybucji. Jest niezwykle prosty i obejmuje tylko dwie kategorie.
Druga kategoria nazywa się nonfree – nazwa nie jest zbyt dobra, gdyż kojarzy się z wszelkiego rodzaju towarami, podróbkami czy koniecznością jakichkolwiek opłat przy ich używaniu. W rzeczywistości jest to całkowicie błędne. Kategoria niewolna obejmuje wyłącznie wolne (w sensie darmowe piwo) i legalnie rozpowszechniane programy. Na ich dystrybucję nakładane są jednak pewne ograniczenia. I dlatego z punktu widzenia FSF nie można ich nazwać prawdziwie wolnymi (w sensie wolne słowo).
Z jednej strony kategoria niewolna obejmuje programy dystrybuowane wyłącznie w formie binarnej – bez żadnych ograniczeń, ale także bez kodu źródłowego. Przykładami takich programów są zastrzeżone sterowniki urządzeń, takich jak karty graficzne i urządzenia sieciowe, odtwarzacz filmów Flash firmy Adobe, przeglądarka Opera, niektóre czcionki i gry.
Z drugiej strony pojęcie nonfree obejmuje programy, które są dostępne w kodzie źródłowym i, zdawałoby się, całkowicie darmowe. Jednak ich dystrybucja w niektórych stanach jest ograniczona ze względów prawnych. Typowym przykładem są oparte na algorytmach kodeki multimedialne, które zostały opatentowane w jednym kraju, który uznaje patenty na algorytmy. W większości innych krajów, które o tym nie pomyślały, ich dystrybucja jest całkowicie legalna.
Zatem kategorie wolny i niewolny są logicznie niezależnymi repozytoriami - i to jest pierwszy powód, dla którego termin ten zwykle pojawia się w liczbie mnogiej. O innych przyczynach dowiemy się na następnej stronie.
Najpierw przyjrzyjmy się głównym repozytoriam, które są automatycznie łączone podczas instalacji RFRemix.
Główne oficjalnie utrzymywane repozytorium Projektu Fedora zawiera wyłącznie darmowe pakiety. I dlatego nazywa się to prosto i bezpretensjonalnie - fedora, z dekodowaniem w postaci numeru wersji i docelowej architektury, na przykład: Fedora 15 - x86_64.
Ale RPMFusion zawiera zarówno pakiety całkowicie bezpłatne, jak i „niewolne”. Dlatego oddziela dwa repozytoria - RPMfusion-free i RPMfusion-nonfree.
Wewnętrzna struktura rosyjskiej Fedory jest jeszcze „bogatsza” - posiada trzy repozytoria:
Jest to główna gałąź repozytorium dla każdego wydania. Towarzyszy mu kilka dodatkowych, które są wypełnione pakietami aktualizowanymi pomiędzy wydaniami:
Ponadto każde z głównych repozytoriów odpowiada specjalnym gałęziom debugowanych i testowanych pakietów: odpowiednio fedora-debuginfo i fedora-updates-testing - dla głównego repozytorium i utworzone w ten sam sposób - dla wszystkich pozostałych.
I wreszcie istnieje gałąź repozytorium surowej skóry. Zawiera pakiety dla kolejnej wersji aktualnie rozwijanej dystrybucji i oczywiście zawiera te same repozytoria, co w gałęziach wydania stabilnego: fedora-rawhide,rpmfusion-free-rawhide,rppmfusion-nonfree-rawhide i tak dalej.
Powyższe dotyczy repozytoriów pakietów binarnych dla architektur i386 oraz x86_64. Istnieją jednak również repozytoria kodu źródłowego - fedora-source, rpmfusion-free-source i tak dalej.
Fedora z Linuksem jest obecnie jedną z najpopularniejszych dystrybucji Linuksa do testowania nowych technologii. Produkt Fedora z Linuksem zasłużenie zyskał zaufanie użytkowników dzięki połączeniu aktualnych programów i ogólnej stabilności. Dystrybucja koncentruje się na budowaniu kompletnego systemu operacyjnego z wolnego oprogramowania.
Projekt Fedora z Linuksem jest bazą testową dla dystrybucji komercyjnej Red Hat Enterprise Linux: przed dodaniem nowych funkcji do RHEL na pewno się pojawiają Fedora. Zmiany przeznaczone dla Red Hat Enterprise Linux, Najpierw są testowane w tej dystrybucji.
Rozwiązanie Fedora z Linuksem przeznaczony dla tych, którzy wolą pracować z zaawansowanymi wersjami programów. W nowym numerze Linux Fedora 13, wprowadzono wiele usprawnień mających wpływ na takie obszary jak konfiguracja urządzeń peryferyjnych, lokalizacja na język rosyjski i inne języki, praca z kontami użytkowników oraz instalacja zestawu dystrybucyjnego przez Internet.
Historycznie rzecz biorąc, proces instalowania pakietów różni się znacznie w różnych dystrybucjach. Same pakiety instalacyjne mają różne formaty. Ten artykuł będzie przydatny dla użytkowników dystrybucji Fedory (źródło).
W starszych wersjach Linuksa (opartych na Red Hat) istniały tylko dwa sposoby instalowania programów. Jest to kompilacja z kodu źródłowego i instalacja z pakietów RPM. Przyjrzyjmy się każdej metodzie bardziej szczegółowo.
Kody źródłowe pobierane są ze strony internetowej programu. Ogólnie rzecz biorąc, aby zainstalować, musisz rozpakować i uruchomić 3 polecenia: skonfiguruj robić I dokonać instalacji. Pierwsze polecenie ma wiele parametrów (możesz je wyświetlić, uruchamiając skonfiguruj - pomoc), takie jak ścieżka instalacji programu, ścieżki do różnych bibliotek i wiele innych. Po pomyślnym ukończeniu pierwszego etapu należy uruchomić polecenie robić. Skompiluje kody źródłowe do plików binarnych. Jeśli kompilacja przebiegła pomyślnie, ostatnie polecenie skopiuje skompilowane pliki do ich katalogów. Zaletą tej metody instalacji jest po pierwsze to, że 99% wszystkich programów typu open source jest dystrybuowanych w kodzie źródłowym, a żądany program może nie mieć pakietu RPM (obecnie jednak format RPM stał się bardzo rozpowszechniony i prawie wszyscy programiści spróbuj utworzyć pakiety w tym formacie). Po drugie, zawsze możesz edytować kod źródłowy zainstalowanego programu, poprawiając błąd lub wprowadzając niezbędne zmiany. Minus jest tylko jeden - aby skorzystać z tej metody trzeba znać język programowania C/C++ i architekturę systemu operacyjnego. Dlatego nie każdy może skorzystać z tej metody, zwłaszcza jeśli wystąpią jakiekolwiek błędy.
Instalacja z pakietu RPM odbywa się w następujący sposób: musisz pobrać pakiet RPM i uruchomić tylko jedno polecenie: obr/min -Uvh ./nazwa_pakietu.rpm(Gdzie nazwa_pakietu– nazwa pliku pakietu). Ta metoda jest nie tylko znacznie prostsza, ale także szybsza, ponieważ program jest już skompilowany w pakiecie (kompilacja programu może zająć sporo czasu, w zależności od mocy twojego komputera). Jednak metoda również nie jest idealna, ponieważ często zdarza się, że do swojej instalacji program wymaga zainstalowania także innych pakietów (na przykład z niezbędnymi bibliotekami) - pojawiają się tzw. Zależności. Jeśli program wymaga jednej biblioteki, nie ma problemu, ale program może wymagać 10 lub więcej bibliotek, z których każda z kolei może również wymagać instalacji bibliotek. Dlatego czas instalacji programu może zająć dużo czasu.
Jednak w najnowszych wersjach Fedory, wraz z pojawieniem się narzędzia konsolowego takiego jak yum, instalowanie programów jest bardzo przyjemne. Aby to zrobić wystarczy wpisać w konsoli polecenie: mniam, nazwa instalacji(Gdzie nazwa– nazwa programu do zainstalowania). Nie tylko to mniam Pobierze wymagany pakiet z Internetu i zainstaluje program; pobierze również i zainstaluje wszystkie potrzebne do tego programy. Jeśli nie lubisz korzystać z konsoli, na przykład w KDE, uruchom program z menu System / Instalacja / Dezinstalacja programy i zainstaluj program za pomocą interfejsu GUI.
Po pomyślnym zakończeniu instalacji Stacja robocza Fedora 24 nie jest jeszcze gotowa do pełnego działania. Pomimo faktu, że twórcy dystrybucji skonfigurowali już wiele programów do pracy z dokumentami, multimediami i systemem plików, nadal istnieje kilka rzeczy, które nie są uwzględnione w dystrybucji od razu po wyjęciu z pudełka.
W tym artykule przyjrzymy się najważniejszym krokom po zainstalowaniu Fedory 24. Dopiero po wykonaniu wszystkich tych kroków Twój system będzie w pełni gotowy do użycia. Tę listę można kontynuować w nieskończoność, ale rozważymy tylko najważniejsze.
Możesz myśleć, że to nie ma znaczenia. Jednak od czasu wydania systemu mogły już zostać wykryte pewne problemy i opracowano dla nich poprawki. Mogą także zostać udostępnione nowe wersje programów. Dlatego aktualizujemy system do najnowszej wersji:
Aby skonfigurować nazwę komputera, która będzie wyświetlana w terminalu i innych programach, skorzystamy z narzędzia hostnamectl. Może ustawić różne rodzaje nazw hostów. Aby wyświetlić bieżącą nazwę hosta, wpisz:
Możesz zmienić nazwę hosta za pomocą następującego polecenia:
hostnamectl set-hostname „losst”
Serwery bardzo często korzystają ze statycznych adresów IP. Jedną z pierwszych rzeczy, które musisz zrobić po zainstalowaniu Fedory, jest skonfigurowanie sieci. Jeśli masz taką opcję, otwórz i edytuj plik konfiguracyjny eth0 lub enp2s0 w folderze /etc/sysconfig/network-scripts/:
vi /etc/sysconfig/network-scripts/ifcfg-enp0s3
Oto ustawienia, które musisz dodać:
Może to być na przykład taka konfiguracja:
BOOTPROTO=statyczny
ONBOOT=tak
IPADDR=192.168.1.1
MASKA SIECI=255.255.255.0
BRAMA=192.168.1.1
DNS1=202.88.131.90
DNS2=202.88.131.89
Aby zastosować zmiany, uruchom ponownie usługi sieciowe:
systemctl zrestartuj usługę sieciową
Aby wyświetlić zmiany, możesz użyć polecenia:
Konfigurowanie Fedory po instalacji powinno obejmować skonfigurowanie dodatkowych repozytoriów. Niektórych pakietów nie ma w oficjalnych repozytoriach RHEL i Fedora. Możesz jednak zainstalować te pakiety z repozytorium RPMFusion. Istnieją tutaj zarówno pakiety autorskie, jak i bezpłatne. Aby dodać repozytorium, uruchom komendę:
sudo obr/min -ivh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-24.noarch.rpm
Domyślnie środowisko graficzne Gnome może nie wyglądać tak, jak byśmy sobie tego życzyli. Narzędzie GNOME Tweak pomaga dostosować wiele ustawień wyglądu Fedory 24, panelu, przestrzeni na pulpicie i nie tylko.
Możesz go zainstalować, otwierając Centrum aplikacji, wyszukując Gnome Tweak i klikając przycisk Instaluj:
Fedora 24 umożliwia dostęp do kont online bezpośrednio z systemu. Można je skonfigurować podczas instalacji. Jeśli jednak tego nie zrobiłeś, zawsze możesz to zrobić w ustawieniach, w zakładce Osobiste, w kontach online:
Gnome Shell umożliwia instalowanie rozszerzeń ułatwiających konfigurację systemu i zarządzanie nim.
Następnie zainstaluj za pomocą polecenia:
obr/min zainstaluj plik teamviewer.rpm
To daleko od wszystkich działań, które należy wykonać po zainstalowaniu Fedory 24, ale najważniejsze jest tutaj zebrane. Jeżeli coś zostało pominięte, napisz w komentarzach.
W starszych wersjach Linuksa (opartych na Red Hat) istniały tylko dwa sposoby instalowania programów. Jest to kompilacja z kodu źródłowego i instalacja z pakietów RPM. Przyjrzyjmy się każdej metodzie bardziej szczegółowo.
Kody źródłowe pobierane są ze strony internetowej programu. Ogólnie rzecz biorąc, aby zainstalować, musisz rozpakować i uruchomić 3 polecenia: skonfiguruj robić I dokonać instalacji. Pierwsze polecenie ma wiele parametrów (możesz je wyświetlić, uruchamiając skonfiguruj --pomoc), takie jak ścieżka instalacji programu, ścieżki do różnych bibliotek i wiele innych. Po pomyślnym ukończeniu pierwszego etapu należy uruchomić polecenie robić. Skompiluje kody źródłowe do plików binarnych. Jeśli kompilacja przebiegła pomyślnie, ostatnie polecenie skopiuje skompilowane pliki do ich katalogów. Zaletą tej metody instalacji jest po pierwsze to, że 99% wszystkich programów typu open source jest dystrybuowanych w kodzie źródłowym, a żądany program może nie mieć pakietu RPM (obecnie jednak format RPM stał się bardzo rozpowszechniony i prawie wszyscy programiści spróbuj utworzyć pakiety w tym formacie). Po drugie, zawsze możesz edytować kod źródłowy zainstalowanego programu, poprawiając błąd lub wprowadzając niezbędne zmiany. Minus jest tylko jeden - aby skorzystać z tej metody trzeba znać język programowania C/C++ i architekturę systemu operacyjnego. Dlatego nie każdy może skorzystać z tej metody, zwłaszcza jeśli wystąpią jakiekolwiek błędy.
Instalacja z pakietu RPM odbywa się w następujący sposób: musisz pobrać pakiet RPM i uruchomić tylko jedno polecenie: obr/min -Uvh ./nazwa_pakietu.rpm(Gdzie nazwa_pakietu- nazwa pliku pakietu). Ta metoda jest nie tylko znacznie prostsza, ale także szybsza, ponieważ program jest już skompilowany w pakiecie (kompilacja programu może zająć sporo czasu, w zależności od mocy twojego komputera). Jednak metoda również nie jest idealna, ponieważ często zdarza się, że do swojej instalacji program wymaga zainstalowania także innych pakietów (na przykład z niezbędnymi bibliotekami) - pojawiają się tzw. Zależności. Jeśli program wymaga jednej biblioteki, nie ma problemu, ale program może wymagać 10 lub więcej bibliotek, z których każda z kolei może również wymagać instalacji bibliotek. Dlatego czas instalacji programu może zająć dużo czasu.
Jednak w najnowszych wersjach Fedory, wraz z pojawieniem się narzędzia konsolowego takiego jak yum, instalowanie programów jest bardzo przyjemne. Aby to zrobić wystarczy wpisać w konsoli polecenie: mniam, nazwa instalacji(Gdzie nazwa- nazwa programu do zainstalowania). Nie tylko to mniam Pobierze wymagany pakiet z Internetu i zainstaluje program; pobierze również i zainstaluje wszystkie potrzebne do tego programy. Jeśli nie lubisz korzystać z konsoli, na przykład w KDE, uruchom program z menu System / Instalacja / Dezinstalacja programy i zainstaluj program za pomocą interfejsu GUI.
