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

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 ).

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ęć.

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)

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.

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ść.