Różnice w zarządzaniu pakietami między Debianem a Arch


9

Dyskusja z tego postu zainteresowała mnie różnicami między zarządzaniem pakietami Debian i Arch. Ponadto ludzie twierdzą, że Arch jest bardzo lekki, więc zastanawiam się, co to ma wspólnego z zarządzaniem pakietami. Czy może dlatego, że Debian domyślnie traktuje Polecenia jako twarde zależności?

Czy możesz również wspomnieć o elastyczności / mocy między dwoma menedżerami pakietów: który z dwóch pozwala ci zrobić więcej?

Wiem, że niektóre funkcje dostępne w systemie zarządzania pakietami Debiana byłyby nieistotne w systemie Arch, ponieważ Arch ma jeden pakiet, a Debian ma wiele (np. Przypinanie APT i zaawansowana obsługa zależności), więc proszę porównać funkcje, które mają zastosowanie do obu systemów (tzn. zakładam, że w Debianie używam tylko niestabilnej ).


UWAGA : Przez zarządzanie pakietami Debiana mam na myśli APT, aptitude i dpkg. Nie znam narzędzi Arch, więc nie wiem, czy jest coś innego niż Pacman.
tshepang,

Odpowiedzi:


7

Po prostu używam łuku regularnie od kilku tygodni i nie jestem ekspertem w tej dziedzinie, więc ta odpowiedź nie jest wyczerpująca, tylko kilka punktów, które zauważyłem na temat „elastyczności / mocy”:

  • To tylko wrażenie, ale Pacman wydaje się bardziej nowoczesny i prosty w swojej konstrukcji / architekturze. Przynajmniej jest o wiele mniej narzędzi do radzenia sobie. Chociaż nie znam kodu źródłowego apt, zdarzyło mi się po prostu spojrzeć na kod libalpm (podstawową bibliotekę Pacmana), aby zrobić bardzo prostą łatkę, i wydaje się czysty i łatwy do zrozumienia.

  • Jest również bardzo szybki (ze względu na optymalizację, a także prawdopodobnie przez dbanie o kilka rzeczy (patrz poniżej)). Ostatnia wersja (Pacman 3.5, kilka dni) próbowała poprawić wydajność poprzez zmniejszenie liczby zaangażowanych plików bazy danych.

  • Podczas gdy arch jest zorientowany na użycie pakietów binarnych, ma również zalety przy budowaniu pakietów ze źródła, z systemem kompilacji podobnym do portów BSD (ABS).

  • Tworzenie pakietów jest bardzo łatwe i szybkie, wystarczy kilka wierszy w pliku PKGBUILD i gotowe, nie trzeba zajmować się kontrolą / regułami / prawami autorskimi / dziennikiem zmian / niczym z pakietami Debiana. Po kilku kliknięciach interfejsu użytkownika pakiet jest udostępniany wszystkim w AUR (Arch User Repository).

Rzeczy, które otrzymuję w Debianie, a nie w łuku:

  • Wyzwalacze / hooks (co powoduje, że apt aktualizuje pamięć podręczną ikon, mandb lub cokolwiek innego, po prostu patrząc na to, gdzie pakiet instaluje pliki, bez potrzeby, aby program pakujący zrobił cokolwiek) (wydaje się, że istnieją plany wdrożenia tego).

  • debconf (nic wielkiego, a przy okazji zmuszając mnie do robienia rzeczy ręcznie, zmusza mnie do tego, aby wiedzieć, co dokładnie zostało zrobione) i właściwą obsługę nowych plików konfiguracyjnych (chciałbym przynajmniej wiedzieć, kiedy plik konfiguracyjny w nowym pakiecie wersja różni się od zainstalowanej, ponieważ została zmieniona w nowej wersji lub ponieważ zmodyfikowałem ją lokalnie).

  • podpisywanie pakietów (wygląda na to, że nad tym pracujemy ).

Ponieważ arch jest lekki, jedynym prawdziwym powodem jest to, że jest dostarczany z kilkoma domyślnie instalowanymi pakietami i zachęcamy Cię do dodania tego, czego potrzebujesz, więc prawdopodobnie nie instalowanie opcjonalnych zależności domyślnie zachęca użytkowników do instalacji, aby uniknąć wzdęć.


Nie mogę tego przeanalizować: ale mogę się bez tego obejść i przy okazji wiedzieć, co robię lepiej . W ostatnim zdaniu jest też literówka.
tshepang

W jakim języku jest napisany menedżer pakietów Pacman? Czy ma funkcje zarządzania pakietami niskiego i wysokiego poziomu podobne do dpkg / apt, a jeśli tak, to jak się je nazywa?
Faheem Mitha

@Tshepang: przepraszam, nie-rodzimy użytkownik języka angielskiego tutaj. Miałem na myśli: „nie jest dla mnie wielkim problemem brak tej funkcji (debconf), a zmuszanie mnie do robienia rzeczy ręcznie zmusza mnie do tego, aby wiedzieć, co dokładnie zostało zrobione”.
gentledevil

@Faheem Mitha: Pacman jest napisany w C i stanowi nakładkę na libalpm, która obsługuje zarządzanie pakietami „wysokiego poziomu” i „niskiego poziomu”.
gentledevil

@zanko: Nie jestem też native speakerem. Chciałem tylko, aby zdanie było jaśniejsze, a nie w komentarzu, ale w samym poście. BTW, literówka, o której wspomniałem, jest opcjonalna . Mógłbym sam edytować post, ale pomyślałem, że równie dobrze możesz go naprawić wraz z częścią wyjaśniającą.
tshepang

6

Swoją przygodę z Linuksem rozpocząłem od Ubuntu lucid, a obecnie korzystam z Arch. Napisałem garść pakietów Arch i powiem, że jest to o wiele łatwiejsze niż pisanie pakietów Debiana. Chciałbym jednak zwrócić uwagę na @gentledevil, że Arch ma system przechwytujący pakiety, znany jako install file.

Zasadniczo jest nazwany ${pkgname}.installi zawiera kilka funkcji przed / po instalacji / usuwania / aktualizacji; po prostu umieść w nim aktualizacje pamięci podręcznej czcionek i tak dalej, a to będzie działać tak samo jak haki Debiana.

Zauważyłem również, że wspomniałeś o „przypinaniu” aplikacji za pomocą narzędzi do zarządzania pakietami debian; Pacman Archa ma również tę wbudowaną, /etc/pacman.confakceptuje szereg ustawień, w tym IgnorePkg =, które zapobiegną aktualizacjom pakietów wymienionych po równości (rozdzielone spacjami)


1
Ponadto, chociaż nie jest to pakiet repo, możesz użyć powerpillotoki dla pacmana, aby równolegle pobierać wiele pakietów, więc zamiast pacman -S libfoo libbar libbazpobierać każdy pakiet jeden po drugim, zamiast tego pobierałby wszystkie trzy jednocześnie, znacznie zwiększając prędkości aktualizacji dla lepszych połączeń.
hanetzer

-1

Zanim przejdę za daleko, zapoznaj się z osią czasu Pictorial Linux

Aby zrozumieć różnice w Menedżerach pakietów, musisz zrozumieć filozofie systemów operacyjnych przedstawione powyżej


Trzej główni rodzice

  1. Redhat, teraz Fedora - Package Manger - RPM, skrót od Redhat Package Manager, wiersz poleceń rpm
  2. Slackware - Menedżer pakietów - tgz, zwykłe pliki spakowane. Chociaż są to tylko skompresowane pliki, zostały one zbudowane przez Slackware w górę i umieszczone w repozytorium, czasami nazywanym portem
  3. Debian - DEB, skrót od Debian, to narzędzie wiersza poleceń to Aptitude or Apt

Ci Rodzice są matkami i ojcami większości znanych nam dystrybucji. Idea / koncepcja Systemu Zarządzania Pakietami została wyprowadzona lub udostępniona w jakiejś formie lub modzie. Niezależnie od tego, wszyscy ci rodzice są dystrybutorami binarnymi, co oznacza, że ​​program jest pakowany i wybierany przez stronę trzecią, a następnie przechowywany w repozytorium i wykorzystywany lub instalowany przez bazę użytkowników.

3 nieletnich rodziców

  1. Linux od podstaw - oparty na źródłach, bez menedżera pakietów.
  2. Gentoo - Pochodzi z Linuksa od podstaw . Ta dystrybucja to w zasadzie Linux od podstaw oraz menedżer pakietów o nazwie Portage / emerge
  3. SourceMage - Sorcery Menedżera pakietów

Ci Rodzice są drugorzędni, ponieważ ich baza użytkowników handluje szybkością i łatwością instalacji z mocą i łatwością konfiguracji. Każdy pakiet jest pobierany i kompilowany od podstaw przy użyciu zmiennych i plików konfiguracyjnych.

Most

Arch został stworzony jako pomost między dystrybucją binarną, jak jedno z 3 głównych rodziców, a dystrybucją opartą na źródłach, jak jedno z 3 mniejszych rodziców. Jako taki otrzymuje status nadrzędny na osi czasu, ponieważ żaden inny element nadrzędny nie zapewnił tej funkcji. Pacman ma elastyczność pozwalającą użytkownikowi instalować pakiet binarny z oficjalnego repozytorium lub niestandardowy pakiet zbudowany za pomocą Arch Build System. Ta koncepcja zapewnia równowagę między mocą, jaką dają małoletni rodzice, a łatwością instalacji, którą dają główni rodzice.


Moim zdaniem to nie menedżer pakietów pokazuje moc systemu, ponieważ wszyscy menedżerowie pakietów wykonują to samo zadanie, którym jest zarządzanie i utrzymywanie sprawnego systemu. Jako taki, używany system powinien być określony przez takie czynniki, jak:

  • Poziom użytkownika: ktoś nowy w Linuksie powinien zacząć od głównego rodzica, podczas gdy ktoś sprawny technicznie znajdzie równowagę.
  • Co chcesz zrobić z systemem: Uruchamianie serwera LAMP z podłączonymi użytkownikami jest zupełnie inne niż uruchamianie komputera stacjonarnego do przeglądania stron internetowych i czytania wiadomości e-mail.
  • Poziom komfortu: poziom użytkownika nie ustępuje, jeśli jesteś biegły technicznie, ale nie chcesz spędzić weekendu na kompilacji systemu, wybierzesz głównego rodzica, niezależnie od tego, czy wszyscy, których znasz, wybiorą coś innego.

Jest to bardziej skoncentrowane na genaologii dystrybucji, niż na porównaniu Pacmana i narzędzi zarządzania pakietami Debiana ...
jasonwryan

@ jasonwryan Chodzi o to, że wszyscy menedżerowie pakietów wykonują to samo zadanie, tzn. emerge packagenamesą takie same jak sudo apt-get install packagename.
eyoung100

Na tym poziomie tak; ale to całkowicie pomija sens pytania, tj. co odróżnia Pacmana od {apt, aptitude}.
jasonwryan

@jasonwryan Odpowiedziałem na to w sekcji Most. Poza tym nie ma różnicy. Jedyne różnice są semantyczne, tj. Jedno polecenie w porównaniu do drugiego. Jeśli PO szuka różnic semantycznych, jest do tego instrukcja.
eyoung100

-3

Nie jest to bynajmniej pełna lub wyczerpująca odpowiedź - plakaty przede mną dawały już bardzo dobre punkty, chciałbym tylko dodać moje 2 centy. Kolejna sprawa - tak naprawdę nigdy nie przywykłem do apt / dpkg. Zawsze wydawało mi się to zbyt skomplikowane, bardzo dobrze czuję się z yum / rpm.

Pacman jest bardzo łatwy w użyciu, co jest zaletą i zaletą - możesz nauczyć się go używać (budowanie pakietów na bok) w ciągu jednego popołudnia - używa głównie intuicyjnych i kompletnych funkcji zarządzania pakietami, ale - i to jest duże, ale - jest niezwykle nieelastyczny.

Jeśli projektanci nie pomyśleli wcześniej o jakiejś funkcji, jesteś zepsuty.

Kilka przykładów: w Pacmanie nie ma natywnej wersji. Jeśli chcesz obniżyć wersję pakietu - musisz pobrać tę konkretną wersję pakietu i użyć opcji -U (aktualizacja), aby zainstalować z pliku. Jest bardzo nastawiony na zawsze używanie najnowocześniejszych pakietów w twoim systemie.

Nie ma prawdziwego wewnętrznego czyszczenia pamięci podręcznej / całkowitej przebudowy. Jeśli (z powodu problemu z siecią) pobieranie pakietu zostało uszkodzone, np. Podczas -Syu, komunikat o błędzie, mimo że jest dokładny, nie będzie przydatny - nie będzie wskazywał uszkodzonego pakietu nawet przy włączonej „pełnej” gadatliwości i debugowaniu , i żadna ilość -Syyc nie wyczyści pamięci podręcznej i ponownie pobierze pakiety. Dobrą wiadomością jest to, że -Sc poinformuje cię, gdzie są pobrane pakiety, dzięki czemu możesz po prostu usunąć szkodliwy pakiet (jeśli możesz dowiedzieć się, który to jest) lub wszystkie z nich i ponownie uruchomić -Syu.

Integracja pacmana z dkms jest również nieco problematyczna - podczas instalowania nowego jądra ciągle miałem błędy z dkms. Korzystanie z dkms build && dkms install na nowym jądrze działało bez żadnych problemów, ale Pacman nie podałby żadnych informacji, dlaczego dkms zawiódł podczas aktualizacji jądra (podejrzewam, że nigdy nie przeszedł poprawnej ścieżki nowego jądra i po prostu pozwól dkms użyć domyślnej (aktualnie działające) jądro, ale z niewłaściwą wersją).

Kolejna anegdota na temat jej elastyczności - jak powiedziano, jestem przyzwyczajony do rpm / yum. Jeśli mam plik w systemie i chcę wiedzieć, który pakiet jest jego właścicielem, mogę uruchomić yum dostarcza / path / to / file i uzyskać WSZYSTKIE pakiety, które mogą go tam umieścić - nawet jeśli żaden z nich nie jest zainstalowany. Jeśli plik został umieszczony ręcznie, a teraz chcę zainstalować pakiet - zmieni on nazwę nowego (dodaj rozszerzenie .rpmnew) i pozwól mi wybrać, czego użyć.

pacman po prostu mylnie stwierdza, że ​​plik już istnieje, ale z całkowicie nieistotnym komunikatem o błędzie - narzeka na konflikty między „prawdziwym” właścicielem pliku a aktualnie zainstalowanym pakietem „systemów plików”, tak jakby był także właścicielem tego samego pliku. Ponadto jest on głównie ukierunkowany na informacje o lokalnych instalacjach - próba uzyskania informacji (takich jak listy plików i własność) pakietów, które nie zostały jeszcze zainstalowane, jest mniej intuicyjna.

Mówiąc najprościej - nie jest tak dojrzały jak mniam i prawdopodobnie dpkg, co nadaje mu łatwość użycia, to także względna sztywność.


1
Bez kompleksowego braku odpowiedzi, istnieje wiele kwestii, które podnosisz, które są naprawdę wynikiem nieznajomości Pacmana. Na przykład pacman -Qo $filepowie ci, który pakiet posiada plik $. Poza tym cała twoja odpowiedź jest beznadziejna, ponieważ OP wyraźnie poprosił o różnice między Arch a Debianem - yumnie ma z tym nic wspólnego ...
jasonwryan

dlatego wyraźnie ujawniłem ten fakt na początku mojej odpowiedzi. jak w przypadku pliku -Qo $ - czy kiedykolwiek próbowałeś tego dla pakietu, który nie został jeszcze zainstalowany?
Dani_l

Nie ma sensu próbować tego w przypadku niezainstalowanego pakietu; istnieją do tego inne narzędzia. Ujawnienie nie ogranicza faktu, że nie odpowiedziałeś na pytanie: „porównanie” między yum i pacman nie jest tym samym, co różnice między menedżerami pakietów Debiana i Archa.
jasonwryan

@jasonwryan Oczywiście jest sens. To, że nie widzisz potrzeby ustalenia, który pakiet może posiadać plik, nawet jeśli nie jest jeszcze zainstalowany, nie oznacza, że ​​taka potrzeba nie istnieje. O to właśnie chodziło. Jeśli chodzi o inne narzędzia - czy wymagają one znajomości? pacman jest menedżerem pakietów. Jeśli chodzi o twój główny punkt - mogłem całkowicie błędnie odczytać pytanie, ale założyłem, że dotyczy ono lekkiego PM w porównaniu do bardziej złożonego PM. Zakładam, że apt / dpkg jest co najmniej tak złożony jak yum / rpm, jeśli chodzi o cechy.
Dani_l

Chodzi mi o to, że odpowiadasz na pytanie dotyczące porównywania jabłek z pomarańczami, porównując swoje ograniczone rozumienie jabłek z gruszkami. I tak, całkowicie błędnie odczytałeś pytanie ...
jasonwryan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.