Jakie są zalety / wady deb vs. rpm?

171

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?

Evan
źródło

Odpowiedzi:

86

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.

wzzrd
źródło
9
Aby poprawić cię w kwestii pakietów Debiana, debiankatalog istnieje w katalogu, do którego wyodrębniono źródło źródłowe, a Debian bardzo docenia koncepcję nieskazitelnego archiwum źródłowego. Kiedy budowany jest pakiet źródłowy, istnieją trzy (dwa dla pakietów rodzimych) pliki, które razem nazywane są pakietem źródłowym: archiwum wyjściowe (najlepiej nieskazitelne, polityka Debiana wymaga przepakowania niektórych projektów), archiwum katalogu debian dla nowy format 3.0, (diff dla starego formatu 1.0) i .dsc.
Umang,
8
Katalog debian nie iść do górnego archiwum, pozostaje w .diff.gzlub w .debian.tar.gzplikach pakietu źródłowego, mimo że debiankatalog jest wewnątrz drzewa źródłowego, gdy pakiet źródłowy jest pobierany. BTW: gdy polityka nie wymaga przepakowywania, MD5 tarballa musi pasować do wcześniejszych. Ponadto, aby wyjaśnić, łatki, które sprawiły, że mój opiekun do źródłowego źródła są przechowywane w katalogu debian (format źródłowy 3.0) i .diff.gz(format 1.0).
Umang,
Umang, dzięki za korektę. Usunę część o zmianie tarballa, aby upewnić się, że nikt nie pomylił się.
wzzrd
2
Wygląda teraz dobrze, ale nadal masz „Dla RPM ważne jest, aby używać dokładnie tego samego tarballa, co ten, który wydaje projekt upstream, aż do znacznika czasu”. Z powodu mojego całkowitego braku doświadczenia z RPM, nie wiem, czy różnica w polityce jest ogromna, ale, jak powiedziałem, deweloper Debian będzie nalegał, aby była dokładna do znacznika czasu, chyba że archiwum wysyłane z góry narusza politykę Debiana i musi być przepakowanym.
Umang,
7
@wzzrd, tak naprawdę łatwo jest umieścić pliki źródłowe w katalogu dla poszczególnych pakietów, definiując% _specdir i% _sourcedir w pliku ~ / .rpmmacros.
mattdm,
94

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.

vdboor
źródło
@Tshepang: naprawiono
vdboor
12
Moim zdaniem, gardziłem RPM z dokładnie tego powodu, o którym wspomniałeś: „RPM cierpiał także z powodu stron takich jak rpmfind, gdzie można znaleźć ponad 10 niekompatybilnych pakietów dla różnych dystrybucji”. Zbyt trudno mi też znaleźć RPM dla oprogramowania, którego potrzebuję. Natomiast dla DEB: „Apt całkowicie ukrył ten problem dla pakietów DEB, ponieważ wszystkie pakiety zostały zainstalowane z tego samego źródła.” które są naprawdę łatwe do znalezienia i użycia. DEB zawsze wydaje się lepiej znajdować i instalować zależności, podczas gdy RPM zawsze pozwala mi się zawiesić ... moja opinia po 15 latach używania obu!
Jeach
2
Uważam, że ta odpowiedź dotyczy pytania z punktu widzenia konsumenta, w przeciwieństwie do @ wzzrd's, który jest całkowicie skoncentrowany na programistach / programach pakujących. Również bardzo jasne na temat separacji poziomów.
GnP
1
Twój tekst został skopiowany do WikiVS , wygląda na to, że został poprawnie przypisany.
Martin Ueding,
1
Z punktu widzenia użytkownika jest to najlepsza odpowiedź. Dodam, że korzystanie z PPA jest znacznie prostsze niż dodawanie nowego repozytorium yum.
Marco Sulla,
39

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.

Gilles
źródło
2
Wygląda na to, że obecnie zapisuje nowy plik konfiguracyjny *.rpmnewzamiast spychania zmodyfikowanego - przynajmniej na openSUSE.
Evan,
1
Oba są gotowe, więc otrzymujesz rozproszenie plików rpmsave i rpmnew.
Burhan Ali,
4
Mylisz się, jeśli RPM nie używają standardowych formatów. RPMS używa CPIO dla sekcji danych - która jest standardowym formatem archiwum. Pozostałe sekcje to głównie nagłówki. Możesz użyć narzędzia rpm2cpio, aby wyodrębnić tylko sekcję danych RPM i wyodrębnić pliki zawarte w rpm. Na przykład: rpm2cpio foobar.rpm | cpio -idmv
Tuxdude
... i jest rpm2cpio.shdla osób skłonnych.
Michael Shigorin
Jedyną przełomową zmianą debformatu, który pamiętam, było kiedy się data.tar.gzstał data.tar.xz, w którym to momencie starszy dpkgprzestał być w stanie otwierać nowe pakiety.
mtraceur
19

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

Maciej Piechotka
źródło
6
Czy „rosnąca popularność” nie jest w zasadzie „Ubuntu opiera się na Debianie, więc wiesz, proszę bardzo”.
mattdm,
„dpkg vs yum” jest błędnym porównaniem, ponieważ ten pierwszy jest menedżerem pakietów, ale drugi nie jest (tak samo jak apt / aptitude są menedżerami poziomu repozytorium, a nie tylko „pakietem”).
Michael Shigorin
13

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

arielf
źródło
Chodzi raczej o „redhat vs canonical” (z kanonicznym czerpaniem z tego, co debian robi od dwóch dekad), a nie o „rpm vs deb” - mówię to jako członek zespołu ALT Linux Team.
Michael Shigorin
Tak, dokładnie. I dobrze powiedziane.
arielf
12

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.

Shawn J. Goff
źródło
8

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.

Luc Stepniewski
źródło
6

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.

Johansson
źródło
7
Nazywanie RPM „zastrzeżonymi” jest nieco mocne. Istnieje kilka dodatkowych nagłówków, ale rdzeniem RPM jest skompresowane gzip archiwum CPIO. Istnieje narzędzie dostarczane z RPM o nazwie rpm2cpio, które pozwala wyodrębnić ten rdzeń, abyś mógł z nim grać tak samo, jak z plikiem .deb.
Warren Young,
4
Śmieci. RPM nie są zastrzeżonymi plikami binarnymi. Kiedyś były budowane wokół cpio (które jest stare, tak, ale nie zastrzeżone), podczas gdy nowsze wersje RPM używają xz, który jest również dostępny jako open source.
wzzrd
Tak, zacytowałem to, ponieważ oczywiście nie jest to prawnie zastrzeżone i właśnie o to mi chodzi: dodatkowe nagłówki itp., Więc nie jest to całkiem prosty plik ar jak deb. Nie jest to wielka sprawa, tylko drobna rzecz.
johansson,
5
Być może powinieneś zamienić „zastrzeżone pliki binarne” na „pliki archiwów z dodanymi niestandardowymi nagłówkami”.
Ryan Thompson,
Zainteresowani mogą znaleźć rpm2cpio.shskrypt.
Michael Shigorin,
5

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.

deszyfrator
źródło
IMHO usługa budowania openSUSE jest najfajniejszą rzeczą, która pojawia się od dłuższego czasu. Naprawdę zrobili to dobrze.
Archie
Chociaż chodzi o deb vs rpm, masz rację, zypper jest świetny ze wsparciem dla repozytoriów z priorytetami i niesamowitym solwerem SAT.
drahnr
5

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

Mike Gray
źródło
1
Cześć @MikeGray. Link jest zepsuty. Czy możesz to zaktualizować?
olibre
4

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.

tex
źródło
Wszystkie te rzeczy są również prawdziwe, na przykład dla pakietów RPM dla Fedory.
mattdm
1
Narzędzia do generowania zależności Debiana są prawie nieobecne, jesteśmy o wiele dalej w ALT Linux (dystrybucja oparta na RPM z wykorzystaniem APT).
Michael Shigorin,
3

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

mtraceur
źródło