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

Po prostu używam arch 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 / siły”:

• To tylko wrażenie, ale pacman wydaje się bardziej nowoczesny i prosty w swojej architekturze / konstrukcji. Przynajmniej jest znacznie mniej narzędzi, którymi trzeba się zająć. Chociaż nie wiem o kodzie źródłowym apt, po prostu spojrzałem na kod libalpm (podstawowa biblioteka pacmana), aby stworzyć bardzo prostą łatkę i wydaje się, że jest czysty i łatwy do zrozumienia.

• Jest również bardzo szybki (ze względu na optymalizację, a także prawdopodobnie z uwagi na kilka rzeczy (patrz poniżej)). Ostatnia wersja (pacman 3.5, sprzed kilku dni) próbowała poprawić wydajność, zmniejszając liczbę zaangażowanych plików baz danych.

• Chociaż arch jest zorientowany na używanie pakietów binarnych, ma również zalety podczas budowania pakietów ze źródeł, z systemem budowania podobnym do portów BSD ( ABS).

• Tworzenie pakietów jest bardzo łatwe i szybkie, zaledwie kilka linii w pliku PKGBUILD i gotowe, nie ma potrzeby zajmowania się kontrolą / zasadami / prawami autorskimi / changelog / cokolwiek podobnego do pakietów Debiana. Za pomocą kilku kliknięć w interfejsie internetowym Twój pakiet jest udostępniany wszystkim w AUR (Arch User Repository).

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

• Wyzwalacze / h ooks (co sprawia, że apt aktualizuje pamięć podręczną ikon, mandb lub cokolwiek innego po prostu patrząc, gdzie pakiet instaluje pliki, bez potrzeby, aby program pakujący nic robił) (wydaje się, że są planuje to zaimplementować).

• debconf (nic wielkiego, a przy okazji zmuszając mnie do robienia rzeczy ręcznie, zmusza mnie do poznania, co dokładnie jest zrobione) oraz poprawną obsługę nowych plików konfiguracyjnych (chciałbym przynajmniej, aby pacman wiedział, kiedy plik konfiguracyjny w nowej wersji pakietu różni się od zainstalowanego, ponieważ został zmieniony w nowej wersji lub dlatego, że zmodyfikowałem go lokalnie).

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

Ponieważ arch jest lekki, jedynym prawdziwym powodem jest to, że zawiera domyślnie zainstalowanych kilka pakietów i zachęcamy do dodania tego, czego potrzebujesz, więc prawdopodobnie nie instalowanie opcjonalnych zależności domyślnie zachęca użytkowników do instalacji, unikaj nadużyć .

Komentarze

• Mogę ' przeanalizować to: ale poradzę sobie bez tego i przy okazji wiem, co robię lepiej . W ostatnim zdaniu jest również literówka.
• 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, jak się nazywają?
• @Tshepang: przepraszam, tutaj angielski nie jest językiem ojczystym. Miałem na myśli ” to nie jest dla mnie wielka sprawa brak tej funkcjonalności (debconf) i zmuszając mnie do robienia rzeczy ręcznie, zmusza mnie to do dokładnego poznania co jest zrobione „.
• @Faheem Mitha: Pacman jest napisany w C i jest nakładką na libalpm, która obsługuje zarówno ” high -level ” i ” niskopoziomowe ” zarządzanie pakietami.
• @zanko: Ja też ' nie jestem native speakerem. Wszystko, co chciałem, to uczynić zdanie jaśniejszym i nie w komentarzu, ale w samym poście. Swoją drogą, literówka, o której wspomniałem, to optionnal . Mógłbym samodzielnie edytować post, ale pomyślałem, że równie dobrze możesz to naprawić razem z częścią wyjaśniającą.

Swoją przygodę z Linuksem rozpocząłem od Ubuntu lucid, a obecnie używam Arch.Napisałem kilka 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 zaczepów dla pakietów, znany jako install file.

Zasadniczo ma nazwę ${pkgname}.install i zawiera kilka funkcji przed / po instalacji / usunięciu / uaktualnieniu; po prostu umieść aktualizacje pamięci podręcznej czcionek w tym i tak dalej, i działa prawie tak samo jak przechwyty Debiana.

Zauważyłem również, że wspomniałeś o „przypinaniu” aplikacji przy użyciu narzędzi do zarządzania pakietami Debiana; Pacman Archa ma to wbudowane również /etc/pacman.conf akceptuje szereg ustawień, w tym IgnorePkg =, co zapobiega uaktualnieniom do pakietów wymienionych po równościach (rozdzielanych spacjami )

Komentarze

• Ponadto, chociaż nie jest to pakiet repo, możesz użyć opakowania powerpill aby pacman mógł równolegle pobierać wiele pakietów, więc zamiast pacman -S libfoo libbar libbaz pobierać każdy pakiet jeden po drugim r zamiast tego pobierałoby wszystkie trzy jednocześnie, znacznie zwiększając prędkość aktualizacji dla lepszych połączeń.

Wcześniej posunąć się za daleko, przestudiuj graficzną oś czasu Linuksa

Aby zrozumieć różnice w menadżerach pakietów, musisz zrozumieć filozofię systemu operacyjnego ” jak pokazano powyżej

Three Major Parents

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

Ci rodzice są matkami i ojcami większości znanych nam dystrybucji. Pomysł / koncepcja systemu zarządzania pakietami została wyprowadzona lub udostępniona w niektórych Niezależnie od formy lub mody. 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 konsumowany lub instalowany przez bazę użytkowników.

3 Nieletni rodzice

1. Linux od podstaw – oparty na źródłach, bez menedżera pakietów.
2. Gentoo – wywodzi się z Linux od podstaw . Ta dystrybucja to zasadniczo Linux from Scratch plus 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ówoferuje szybkość i łatwość 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ł utworzony jako pomost między dystrybucją binarną, jak jeden z 3 głównych rodziców, oraz dystrybucję opartą na źródłach, taką jak jeden z trzech niepełnoletnich rodziców. W związku z tym otrzymuje status rodzica na osi czasu, ponieważ żaden inny rodzic nie zapewnił tej funkcji. Pacman ma elastyczność umożliwiającą użytkownikowi zainstalowanie pakietu binarnego z oficjalnego repozytorium lub niestandardowego pakietu za pomocą Arch Build System. Ta koncepcja zapewnia równowagę między mocą, jaką dają niepełnoletni rodzice, a łatwością instalacji, jaką dają główni rodzice.

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

• Poziom użytkownika: Ktoś nowy w Linuksie powinien zaczynać się od głównego rodzica, podczas gdy ktoś biegły technicznie znajdzie równowagę.
• Co chcesz zrobić ze swoim systemem: uruchomienie serwera LAMP z podłączonymi użytkownikami jest zupełnie inne niż uruchomienie komputera stacjonarnego do przeglądania stron internetowych i czytania e-maili.
• Poziom komfortu: bez względu na poziom użytkownika, jeśli jesteś biegły technicznie, ale nie chcesz spędzać weekendu na kompilowaniu systemu, wybierzesz głównego rodzica, niezależnie od tego, czy wszyscy, których znasz, wybierają coś innego.

Komentarze

• To jest bardziej szczegółowe na podstawie genealogii dystrybucji, a nie porównania narzędzi do zarządzania pakietami Pacmana i Debiana ' …
• @jasonwryan That ' o to chodzi, ponieważ wszyscy menedżerowie pakietów wykonują to samo zadanie, tj. emerge packagename jest tym samym, co sudo apt-get install packagename.
• Na tym poziomie tak; ale to całkowicie mija się z celem pytania, tj. co odróżnia pacmana od {apt, aptitude}.
• @jasonwryan Odpowiedziałem na to w sekcji Most. Poza tym nie ma różnicy. Jedyne różnice są semantyczne, tj. Jedno polecenie a drugie.Jeśli OP szuka różnic semantycznych, jest do tego instrukcja.

To jest przez nie oznacza kompletnej lub wyczerpującej odpowiedzi – plakaty przed mną zawierały już kilka bardzo dobrych punktów, chciałbym tylko dodać moje 2 centy. Inna sprawa – nigdy nie przyzwyczaiłem się do apt / dpkg. Zawsze wydawało się to zbyt skomplikowane, ja, naprawdę czuję się najlepiej z yum / rpm.

pacman jest bardzo łatwy w użyciu, co jest zaletą i wadą – możesz nauczyć się go używać (pomijając tworzenie pakietów) w jedno popołudnie – wykorzystuje głównie intuicyjne i kompletne funkcje zarządzania pakietami, ale – i to jest duże, ale – jest wyjątkowo nieelastyczne.

Jeśli projektanci nie pomyśleli wcześniej o funkcji, masz spieprzone.

Kilka przykładów: w pacman nie ma natywnych 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 alwa ys używając najnowocześniejszych pakietów w twoim systemie.

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

Integracja pacmana z dkms też jest nieco problematyczna – podczas instalacji nowego jądra ciągle otrzymywałem błędy z dkms. Korzystanie z kompilacji dkms & & instalacja dkms na nowym jądrze działała bezproblemowo, ale pacman nie oferował żadnych informacji, dlaczego dkms zawiódł aktualizacja jądra (podejrzewam, że nigdy nie przekazała poprawnej ścieżki nowego jądra i po prostu pozwól dkms użyć domyślnego (aktualnie działającego) jądra, ale z niewłaściwą wersją).

Kolejna anegdota na temat nieelastyczności tego jądra – ponieważ stwierdził, że jestem przyzwyczajony do rpm / yum. Jeśli mam plik w swoim systemie i chcę wiedzieć, który pakiet jest jego właścicielem, mogę uruchomić yum udostępnia / path / to / file i pobrać 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 (dodam rozszerzenie .rpmnew) i pozwolę mi wybrać, czego użyć.

pacman po prostu wyświetla błąd, że plik już jest istnieje, ale z zupełnie 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ł on również właścicielem tego samego pliku. Ponadto jest głównie nastawiony na lokalne informacje o 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ła jak yum i prawdopodobnie dpkg, który również zapewnia łatwość użytkowania, jest względną nieelastycznością.

Komentarze

• Krótko mówiąc, brak odpowiedzi, jest kilka punktów, które poruszyłeś, a które w rzeczywistości są wynikiem nieznajomości Pacmana. Na przykład pacman -Qo $file powie Ci, do którego pakietu należy plik $. Ponadto cała twoja odpowiedź jest słomiana, ponieważ OP wyraźnie poprosił o różnice między Arch i Debian – yum nie ma z tym nic wspólnego …
• , dlatego wyraźnie ujawniłem ten fakt na początku mojej odpowiedzi. jeśli chodzi o plik -Qo $ – czy kiedykolwiek próbowałeś tego dla pakietu, który nie jest jeszcze zainstalowany?
• Nie ma sensu próbować tego dla pakietu niezainstalowanego; są do tego inne narzędzia. Ujawnienie nie ' nie złagodzi faktu, że nie ' nie odpowiedziałeś na pytanie: a ” porównanie ” między yum i pacman jest nie tym samym, co różnice między Debian ' s i Arch Menedżery pakietów ' s.
• @jasonwryan Oczywiście jest racja. Tylko dlatego, że nie ' nie widzisz potrzeby ustalenia, który pakiet może posiadać plik, nawet jeśli ' nie jest jeszcze zainstalowany, prawda? ' nie oznacza, że taka potrzeba ' nie istnieje. O to właśnie chodziło. A jeśli chodzi o inne narzędzia – czy trzeba je znać? pacman to menedżer pakietów. Odnośnie twojego głównego punktu – mogłem całkowicie źle odczytać pytanie, ale założyłem, że chodzi o lekkiego PM kontra bardziej złożonego PM. Zakładam, że apt / dpkg jest co najmniej tak złożony, jak yum / rpm, jeśli chodzi o funkcje.
• 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 źle odczytałeś pytanie …