Jakie są zalety / wady deb vs. rpm?

Z jakichkolwiek powodów zawsze korzystałem z dystrybucji opartych na RPM (Fedora, Centos i obecnie openSUSE). Często słyszałem, jak stwierdzano, że deb jest lepszy niż rpm, ale zapytany dlaczego nigdy nie był w stanie uzyskać spójnej odpowiedzi (zwykle zamiast tego dostaje się gorliwych rantingów i obfitych ilości śliny).

Rozumiem, że mogą istnieć jakieś historyczne powody, ale czy w przypadku współczesnych dystrybucji wykorzystujących dwie różne metody pakowania, czy ktoś może podać zalety techniczne (lub inne) jednej kontra drugiej?

Główną różnicą dla opiekuna pakietu (myślę, że byłby to „programista” w języku lingo Debiana) jest sposób łączenia metadanych pakietu i towarzyszących im skryptów.

W świecie RPM wszystkie twoje pakiety (utrzymywane RPM) znajdują się w czymś podobnym ~/rpmbuild. Poniżej znajduje się SPECkatalog dla plików specyfikacji, SOURCESkatalog źródłowych plików archiwalnych RPMSi SRPMSkatalogi, w których można umieścić nowo utworzone RPM i SRPM oraz niektóre inne rzeczy, które nie są teraz istotne.

Wszystko , co ma związek z tworzeniem RPM, znajduje się w pliku specyfikacji: jakie łatki zostaną zastosowane, możliwe skrypty wstępne i końcowe, metadane, dziennik zmian, wszystko. Wszystkie źródłowe pliki tar i wszystkie łaty wszystkich twoich pakietów są w ŹRÓDŁACH.

Teraz osobiście podoba mi się fakt, że wszystko trafia do pliku specyfikacji i że plik specyfikacji jest odrębną jednostką od źródłowego pliku archiwum, ale nie jestem zbyt entuzjastycznie nastawiony do posiadania wszystkich źródeł w ŹRÓDŁACH. IMHO, ŹRÓDŁA są dość zagracone i masz tendencję do gubienia się w tym, co tam jest. Jednak opinie różnią się.

W przypadku RPM ważne jest, aby używać dokładnie tego samego archiwum tar, co ten, który wydaje projekt upstream, aż do znacznika czasu. Zasadniczo nie ma wyjątków od tej reguły. Pakiety Debiana wymagają również tego samego archiwum co upstream, choć polityka Debiana wymaga ponownego zapakowania niektórych archiwów (dzięki, Umang).

Pakiety Debiana mają inne podejście. (Wybacz tutaj jakiekolwiek błędy: mam dużo mniej doświadczenia z debem niż RPM.) Pliki programistyczne pakietów Debiana są zawarte w katalogu na pakiet.

To, co lubię (myślę) w tym podejściu, to fakt, że wszystko jest zawarte w jednym katalogu.

W świecie Debiana nieco bardziej akceptowane jest przenoszenie łat w pakiecie, który nie jest (jeszcze) wcześniejszy. W świecie RPM (przynajmniej wśród pochodnych Red Hat) jest to niezadowolone. Zobacz „FedoraProject: Bycie blisko projektów nadrzędnych” .

Ponadto Debian ma ogromną liczbę skryptów, które są w stanie zautomatyzować ogromną część tworzenia pakietu. Na przykład, utworzenie - prostego - pakietu programu z Pythonem, jest tak proste, jak utworzenie kilku plików metadanych i uruchomienie debuild. To powiedziawszy, plik specyfikacji dla takiego pakietu w formacie RPM byłby dość krótki, a także w świecie RPM istnieje wiele rzeczy, które są obecnie zautomatyzowane.

Wiele ludzie porównują instalowania oprogramowania z apt-getcelu rpm -i, a zatem powiedzieć DEB lepiej. Nie ma to jednak nic wspólnego z formatem pliku DEB. Prawdziwe porównanie to dpkgvs rpmi aptitude/ apt-*vs zypper/ yum.

Z punktu widzenia użytkownika te narzędzia nie różnią się zbytnio. Formaty RPM i DEB to po prostu pliki archiwów z dołączonymi do nich metadanymi. Oba są równie tajemnicze, mają zakodowane ścieżki instalacji (fuj!) I różnią się jedynie subtelnymi szczegółami. Zarówno dpkg -ii rpm -inie mają możliwości dowiedzieć się, jak zainstalować zależności, z wyjątkiem, jeśli zdarzy ci się być podany w linii poleceń.

Oprócz tych narzędzi istnieje zarządzanie repozytoriami w postaci apt-...lub zypper/ yum. Te narzędzia pobierają repozytoria, śledzą wszystkie metadane i automatyzują pobieranie zależności. Ostateczna instalacja każdego pojedynczego pakietu jest przekazywana narzędziom niskiego poziomu.

Od dłuższego czasu apt-getdoskonale radzi sobie z przetwarzaniem ogromnej ilości metadanych naprawdę szybko, a yumzrobienie tego zajęłoby wieki. RPM ucierpiał także na stronach takich jak rpmfind, gdzie można znaleźć ponad 10 niekompatybilnych pakietów dla różnych dystrybucji. Aptcałkowicie ukrył ten problem dla pakietów DEB, ponieważ wszystkie pakiety zostały zainstalowane z tego samego źródła.

Moim zdaniem zyppernaprawdę wypełnił lukę apti nie ma powodu wstydzić się korzystania z dystrybucji opartej na RPM. Jest równie dobry, jeśli nie łatwiejszy w użyciu z dostępną usługą kompilacji openSUSE dla ogromnego kompatybilnego indeksu pakietów.

Z punktu widzenia administratora systemu znalazłem kilka drobnych różnic, głównie w zestawie narzędzi dpkg / rpm zamiast w formacie pakietu.

• dpkg-divertumożliwia usunięcie własnego pliku z pakietu z własnego pliku. Może to być ratownik, gdy masz program, który szuka pliku w /usrlub /libnie chce /usr/localuzyskać odpowiedzi. Pomysł został zaproponowany, ale o ile wiem nie został przyjęty, w obr / min.

• Kiedy ostatnio administrowałem systemami opartymi na rpm (co prawda było lata temu, być może sytuacja się poprawiła), rpm zawsze nadpisywał zmodyfikowane pliki konfiguracyjne i przenosił moje dostosowania do *.rpmsave(IIRC). To spowodowało, że mój system nie uruchomił się przynajmniej raz. Dpkg pyta mnie, co mam robić, zachowując ustawienia domyślne jako domyślne.

• Pakiet binarny rpm może deklarować zależności od plików, a nie pakietów, co pozwala na lepszą kontrolę niż pakiet deb.

• Nie można zainstalować pakietu rpm wersji N w systemie z wersją N-1 narzędzi rpm. Może to dotyczyć również dpkg, z wyjątkiem tego, że format nie zmienia się tak często.

• Baza danych dpkg składa się z plików tekstowych. Baza danych rpm jest binarna. To sprawia, że ​​baza danych dpkg jest łatwa do sprawdzenia i naprawy. Z drugiej strony, dopóki nic nie pójdzie źle, rpm może być znacznie szybszy (instalacja deb wymaga odczytu tysięcy małych plików).

• Pakiet deb używa standardowych formatów ( ar, tar, gzip), dzięki czemu można sprawdzić, w wariację pinch) pakiety deb łatwo. Pakiety RPM nie są tak przyjazne.

RPM:

• „Standaryzowany” (nie to, że nie ma specyfikacji deb)
• Używany przez wiele różnych dystrybucji (ale pakiety z jednej niekoniecznie działają na innej)
• IIRC dopuszcza zależności od plików, nie tylko od pakietów

DEB:

• Rosnąca popularność
• Zezwala na rekomendacje i sugestie (możliwe, że także nowsze wersje RPM)

Prawdopodobnie ważniejszym pytaniem jest menedżer pakietów (dpkg vs. yum vs. aptitude itp.) Niż format pakietu (ponieważ oba są porównywalne).

Jak powiedziało kilka respondentów, nie jest tak bardzo, że pewien format pakietu jest wyraźnie lepszy. Technicznie mogą być mniej więcej porównywalne. Z mojej perspektywy wiele różnic i to, dlaczego ludzie wolą jedno od drugiego, dotyczy:

• Filozofia oryginalnego projektu opakowania i grupy docelowej
• Wielkość społeczności, a co za tym idzie, jakość i bogactwo repozytoriów

Filozofia:

W świecie Ubuntu / Debian / Mint / ... użytkownicy oczekują, że zainstalowany pakiet będzie „działał” po jego zainstalowaniu. Oznacza to, że podczas instalacji pakiety powinny zadbać o wszystko, co jest potrzebne do ich poprawnego działania, w tym między innymi:

• konfigurowanie potrzebnych lub opcjonalnych zadań cron
• tworzenie alternatyw / aliasów
• konfigurowanie skryptów uruchamiania / zamykania
• w tym wszystkie potrzebne pliki konfiguracyjne z wartościami domyślnymi, które mają sens
• utrzymywanie starych wersji bibliotek i dodawanie odpowiednich wersjonowanych dowiązań symbolicznych do bibliotek (.so) w celu zapewnienia kompatybilności wstecznej
• czysta obsługa plików binarnych z wieloma archami (32- i 64-bitowymi) na tym samym komputerze i tak dalej.

W świecie rpm - wprawdzie taka była sytuacja sprzed kilku lat i od tego czasu mogła się poprawić - musiałem wykonać dodatkowe kroki (np. Chkconfig, włączenie zadań crona), aby pakiety rzeczywiście działały. Może to być w porządku dla sysadminów lub osób znających się na Uniksie, ale powoduje to cierpienia dla początkujących. Zauważ, że nie jest tak, że sam format pakietu RPM temu zapobiega, po prostu wiele pakietów de facto nie jest „w pełni zrobionych” z perspektywy nowicjusza.

Wielkość społeczności, udział i bogactwo repozytoriów:

Ponieważ społeczność ubuntu / debian / mint / ... jest większa, więcej osób zajmuje się pakowaniem i testowaniem oprogramowania. Uważam, że bogactwo i jakość repozytoriów jest lepsza. W Ubuntu rzadko, jeśli w ogóle, muszę pobierać źródła i budować z nich. Kiedy przeniosłem się z Red Hat na Ubuntu w domu, typowe repozytorium RHEL zawierało ~ 3000 pakietów, podczas gdy jednocześnie ubuntu + wszechświat + multiwers wszystkie dostępne bezpośrednio z dowolnego lustrzanego Canonical zawierały ~ 30 000 pakietów (około 10x). Większość pakietów, których szukałem w formacie RPM, nie była łatwo dostępna poprzez proste wyszukiwanie i kliknięcie w menedżerze pakietów. Wymagały one przejścia do alternatywnych repozytoriów, przeszukiwania strony internetowej usługi rpmfind itp. W większości przypadków zamiast rozwiązać problem, zepsułem moją instalację, nie ograniczając, jakie zależności można lub nie można poprawnie zaktualizować. Uderzyłem w zjawisko „piekła zależności”, jak opisano powyżej przez Shawna J. Goffa.

W przeciwieństwie do Ubuntu / Debian stwierdziłem, że prawie nigdy nie muszę budować ze źródła. Również z powodu:

• Szybki cykl wydawniczy Ubuntu (6 miesięcy)
• Istnienie w pełni kompatybilnych umów PPA, które działają od razu po wyjęciu z pudełka
• Repozytoria z jednym źródłem (wszystkie hostowane przez Canonical) nie muszą szukać alternatywnych / uzupełniających repozytoriów
• Bezproblemowa obsługa od kliknięcia do uruchomienia

Nigdy nie musiałem iść na kompromis w sprawie starszych wersji pakietów, na których mi zależało, nawet jeśli nie były one utrzymywane przez oficjalnych (kanonicznych) programistów. Nigdy nie musiałem opuszczać mojego ulubionego przyjaznego menedżera pakietów GUI, aby przeprowadzić wygodne wyszukiwanie według słowa kluczowego, aby znaleźć i zainstalować dowolny pakiet, który chciałem. Ponadto kilka razy instalowałem pakiety Debian (nie Canonical) na Ubuntu i działały one dobrze, mimo że oficjalnie nie jest gwarantowana ta kompatybilność.

Zauważ, że to nie ma na celu rozpętania wojny z płomieniami, to po prostu dzielenie się moim doświadczeniem w korzystaniu z obu światów równolegle przez kilka lat (praca kontra dom).

Myślę, że błąd ten nie wynika z formatu pakietu, ale z niespójności, które istniały w repozytoriach RedHata.

Kiedy RedHat był dystrybucją (przed dniami RHEL, Fedory i Fedory Core), ludzie czasami znajdowali się w „Piekle RPM” lub „Piekle zależności”. Stało się tak, gdy repozytorium skończyło się pakietem, który miał zależności (zwykle kilka warstw głębokości), które wzajemnie się wykluczały. Albo powstałoby, gdy dwa różne pakiety miały dwie wzajemnie wykluczające się zależności. Był to problem ze stanem repozytorium, a nie z formatem pakietu. „Piekło RPM” pozostawiło niechęć do systemów RPM wśród populacji użytkowników Linuksa, którzy zostali poparzeni przez problem.

Istnieje również „filozoficzna” różnica polegająca na tym, że w pakietach Debiana można zadawać pytania, a tym samym blokować proces instalacji. Złą stroną tego jest to, że niektóre pakiety będą blokować twoje aktualizacje, dopóki nie odpowiesz. Dobrą stroną tego jest także filozoficzna różnica w systemach opartych na Debianie, kiedy pakiet jest instalowany, jest konfigurowany (nie zawsze tak, jak chcesz) i działa. Nie w systemach opartych na Redhat, w których należy utworzyć / skopiować z / usr / share / doc / * domyślny plik konfiguracji / szablonu.

Jedną z rzeczy, które lubię w RPM, jest (ostatnio?) Dodanie delta RPM. Pozwala to na łatwiejszą aktualizację, zmniejszając wymaganą przepustowość.

DEB to standardowe pliki ar (z większą ilością standardowych archiwów w środku), RPM to „zastrzeżone” pliki binarne. Osobiście uważam, że ten pierwszy jest wygodniejszy.

Tylko dwie rzeczy, które mogę oderwać od głowy. Oba są bardzo porównywalne. Oba mają doskonałe narzędzia do pakowania. Nie sądzę, że jest tyle zalet dla jednego lub drugiego i odwrotnie.

OpenSUSE Build Service (OBS) i zypper to kilka powodów, dla których wolę RPM niż deb ​​z punktu widzenia packagera i użytkownika. Zypper przeszedł długą drogę i jest dość szybki. OBS, chociaż może obsługiwać deb, jest naprawdę fajny, jeśli chodzi o pakowanie rpms dla różnych platform, takich jak openSUSE, SLE, RHEL, centos, fedora, mandriva itp.

Pakiety Debiana mogą zawierać zainstalowany rozmiar , ale nie sądzę, aby RPM miały równoważne pole. Można go obliczyć na podstawie plików zawartych w pakiecie, ale nie można na nim polegać z powodu działań, które można podjąć w skryptach przed / po instalacji.

Oto całkiem niezłe odniesienie do porównania niektórych konkretnych funkcji dostępnych dla każdego konkretnego formatu opakowania: http://debian-br.sourceforge.net/txt/alien.htm (według serwera WWW ten dokument jest dość stary : Ostatnia modyfikacja: niedz., 15 października 2000 r., Więc może to nie być najlepsze odniesienie).

W przypadku pakietów Debiana istnieje duży zestaw skryptów pomocniczych, spójny podręcznik polityki i co najmniej jeden sposób robienia prawie wszystkiego. Zależności są obsługiwane bardzo dobrze i można je zdefiniować z bardzo dobrą szczegółowością. Ponowne budowanie pakietów jest bardzo łatwe dzięki pakietom debian i jest dobrze obsługiwane przez dostępne narzędzia.

Żadna z pozostałych odpowiedzi nie dotyczy tego, jak następujące trzy podstawowe różnice mają realne konsekwencje:

1. debpliki to w zasadzie tylko ararchiwa zawierające dwa skompresowane pliki tar
2. debpakiety i dpkgsystem przechowują skrypty opiekuna jako osobne pliki
3. dpkgi rpmpodczas aktualizacji uruchom skrypty opiekuna w innej kolejności.

Różnice te znacznie ułatwiły mi naprawę problemów spowodowanych przez złe pakiety i sprawienie, że pakiety zachowują się tak, jak ich potrzebuję, w debsystemach bazujących na systemach bazowych niż na rpmsystemach bazowych, zarówno jako administrator systemu, jak i program pakujący .

Z powodu nr 1, jeśli muszę zmienić debplik, mogę go trywialnie otworzyć, dokonać dowolnych zmian i ponownie go spakować, używając standardowych narzędzi, które istnieją w większości systemów .

Obejmuje to zmianę / dodanie / usunięcie wszelkich zależności, plików pakietu lub skryptów opiekuna, a także zmianę wersji lub nazwy pakietu.

Z powodu nr 2, jeśli występuje problem ze skryptami „usuń” zainstalowanymi przez już zainstalowany pakiet , mogę go w prosty sposób naprawić, używając standardowych narzędzi, które istnieją w dowolnym systemie .

Z powodu # 3 mogę wykonać niektóre z tych poprawek, po prostu wypuszczając nową wersję mojego pakietu, ponieważ podczas aktualizacji dpkguruchamia skrypt „przedinstalacyjny” nowej wersji pakietu przed skryptem „po usunięciu” stara wersja.

Oznacza to, że powierzchnia naruszenia zasad „odzysku” jest mniejsza w debpakietach: więcej błędów we wcześniejszej wersji pakietu można odzyskać dzięki nowej wersji.

A ponieważ modyfikacja pakietu jest tak łatwa - faktyczne skrzypowanie i wiedza związana z pakietem jest niewielka - jest dostępna dla większej liczby osób i zajmuje mniej czasu i wysiłku przy debplikach.