Po co używać sbuild zamiast pbuildera?

Istnieje wiele sposobów budowania pakietów Debiana w czystym i powtarzalnym środowisku. Dwa najczęściej używane to pbuilder i sbuild. Osobiście zawsze korzystałem z pbuildera. Uważam, że pbuilder jest znacznie łatwiejszy w użyciu i utrzymaniu. Nie udało mi się znaleźć żadnego porównania między nimi. Czego mi brakuje?

Jakie są zalety korzystania z sbuild nad pbuilderem?

sbuild i pbuilder rozwinęły się przez lata, aby mieć prawie identyczną funkcjonalność, a ponieważ funkcje są dodawane do obu, zwykle są szybko adoptowane przez drugą.

Ponieważ pakiet Debian jest formatem opartym na polityce, stanowi on znaczącą pomoc w ustaleniu, czy dany problem z kompilacją jest błędem w implementacji konstruktora, czy też problemem z budowaniem pakietu, który ma wiele implementacji systemu kompilacji. Aby to utrzymać, wszystkie wiodące systemy kompilacji muszą mieć silnych stronników, którzy je wspierają, w duchu współpracy opartej na współdziałaniu w celu zapewnienia, że ​​mamy najbardziej prawidłowe dostępne wdrożenia polityki.

Wewnętrzna mechanika sbuild i pbuilder różnią się znacznie, więc dokładnie, które pakiety są pobierane w celu spełnienia zależności kompilacji lub w jaki sposób są one pobierane, precyzyjny mechanizm, za pomocą którego wywoływane są różne cele w debian / rules itp., Może się różnić, powodując pewne nieznaczne różnice w zachowaniu w bardzo szczególnych przypadkach dla niektórych pakietów. W większości przypadków stanowi to błąd w jednej lub drugiej implementacji, a czasem odzwierciedla brak jasności w polityce pakowania: w każdym przypadku zmiany zachowania powinny zostać rozwiązane.

Oficjalne wersje zarówno w Debianie, jak i Ubuntu używają sbuild (chociaż często nie jest to sbuild dostępny z archiwów), co jest uważane przez niektórych programistów za zaletę, ponieważ mają większą pewność, że ich konfiguracja pasuje do tego, na który ich pakiet będzie narażony po zbudowaniu, chociaż jeśli wszyscy to zrobią, tracimy możliwość odróżnienia błędów w polityce od błędów w sbuild.

Historycznie rozumiem, że rozwój pbuildera początkowo koncentrował się na potrzebach dewelopera, a rozwój użytkownika końcowego i sbuilda początkowo koncentrował się na potrzebach administratorów buildd i archiwów. Ostatnio skupiono się na tych zagadnieniach, ponieważ ludzie zbudowali systemy zarządzania archiwami oparte na pbuilder i bardziej pomocne narzędzia programistyczne za pomocą sbuild.

Oba narzędzia (lub ich powszechnie dostępne bliskie pochodne) obsługują przechowywanie chrootów jako tarballi, rozpakowane w systemie, w osobnych woluminach (z dostępnymi zaczepami do specjalnego montażu: np. Migawek LVM), przy użyciu nakładkowych systemów plików, przy użyciu semantyki kopiowania przy zapisie itp. Oba narzędzia oferują trywialne narzędzia wiersza poleceń do usprawnienia wspólnej sprawy (testowanie-budowanie pakietu) i zaawansowaną semantykę przechwytującą do obsługi złożonych spraw (duże archiwa). Oba zapewniają środki do stworzenia środowiska testowego w chroot. Krótko mówiąc, oba narzędzia zapewniają prawie wszystko, co możesz chcieć w narzędziu do budowania pakietów (i oba mają aktywne strumienie, chętnie przyjmują błędy i łatki).

Podsumowując: jeśli jesteś zadowolony z pbuildera, używaj go dalej. Jeśli chcesz zagrać w sbuild, nie krępuj się. Najlepsze narzędzie to takie, które zapewnia wygodę podczas wykonywania pracy.

Zawsze niebezpieczne jest nie zgadzać się z Emmetem, więc zacznę od potwierdzenia, że ​​jego odpowiedź jest prawdopodobnie bardziej poprawna. Jednak osobiście uważam, że pbuilder jest bardziej przyjazny dla użytkownika i bardziej wydajny od samego początku.

Jeśli korzystasz z systemu Ubuntu 12.10 lub nowszego, zainstaluj doskonałe skrypty pbuilder, które są zestawem bardzo przyjaznych owijarek wokół surowego pbuildera.

Jeśli korzystasz z systemu Ubuntu 12.04, możesz zainstalować skrypty pbuilder z repozytorium backports.

Teraz porównajmy i porównajmy łatwość obsługi równoważnych operacji. W tych przykładach omówię korzystanie z chroota ARM hostowanego na x86, ale koncepcje nadal dotyczą chroota x86 hostowanego na x86. Pamiętaj, że używam owijaczy skryptów pbuilder.

Należy zauważyć, że skrypty pbuilder implementują trochę konwencji, podobnie jak Ruby on Rails podejmuje pewne decyzje, abyś mógł szybko zacząć. Spróbuję wskazać to na bieżąco.

Utwórz chroot

mk-sbuild --arch=armhf quantal

vs

# in addition to the chroot, creates a new, empty directory named ~/Projects/quantal-armhf
pcreate -a armhf -d quantal quantal-armhf

werdykt: remis , obie linie poleceń są dość proste i obie mogą w razie potrzeby skorzystać z dodatkowych opcji dla bardziej wyszukanych przypadków użycia. Zwróć jednak uwagę na dodatkowy nowy katalog utworzony przez pcreate.

Pobierz pakiet źródłowy

# standard debian/ubuntu method, works in any directory
apt-get source casper

vs.

# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper

werdykt: niewielka przewaga dla sbuild , ponieważ używasz standardowej najlepszej praktyki debian / ubuntu. Konwencja stosowana przez pget może początkowo wydawać się dziwna, ale ponieważ pracuję nad wieloma pakietami w wielu wersjach Ubuntu, podoba mi się organizacja, którą narzuca. Zauważ też, że apt-get source również wypakowuje źródło gdziekolwiek uruchomisz polecenie, pozostawiając ci * .orig.tar.gz, * .debian.tar.gz, * .dsc i rozwinięty katalog, który osobiście znajduję być niechlujnym. Obiecuję, że piękno tej organizacji będzie wkrótce.

Wpisz chroot, efemeryczną wersję

schroot -c quantal-armhf

vs.

ptest quantal-armhf

werdykt: niewielka przewaga kompilacji , mniej znaków do wpisania to mniej znaków. Zwróć uwagę, że w tej wersji wchodzenia do chroot wszelkie wprowadzone tutaj zmiany zostaną utracone po wyjściu z chroot. Zauważ też, że w schroot pozostaniesz normalnym użytkownikiem, podczas gdy z ptest będziesz w chroot jako użytkownik root.

Wprowadź chroot, zapisz zmiany wersji

sudo schroot -c quantal-armhf-source -u root

vs.

ptest quantal-armhf --save

werdykt: niewielka przewaga dla pbuild , mniej znaków i bardziej intuicyjne argumenty wiersza poleceń, moim zdaniem. W tej wersji wprowadzania chroota wszelkie wprowadzone w nim zmiany zostaną zapisane dla przyszłych wywołań.

Zbuduj pakiet w chroot

debuild -S -sa -I -i
sbuild -A --arch armhf -d quantal-armhf /path/to/casper-1.315.dsc

vs.

# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild

werdykt: pbuild , teraz widzimy pierwszą znaczącą wygraną przy użyciu konwencji pbuild. Jest to bardzo prosta komenda, której nie trzeba zapamiętywać, w przeciwieństwie do architektury, nazwy chroot i wymagającej ścieżki do pliku * .dsc wymaganego przez sbuild. Dodatkowo musisz pamiętać o wygenerowaniu nowego pliku * .dsc z sbuild, podczas gdy pbuild zrobi to automatycznie.

Zbuduj ten sam pakiet w chroot, po raz drugi

W powyższym przykładzie zarówno sbuild, jak i pbuild pobiorą i zainstalują build-deps w swoich odpowiednich chrootach. Jednak pbuild zapisuje pobrane pliki .deb w / var, więc jeśli wywołasz pbuild po raz drugi, nie musisz ponownie pobierać wszystkich build-dep (chociaż muszą one być nadal zainstalowane w chroot). sbuild nie buforuje plików .deb (przynajmniej domyślnie), dlatego musisz ponownie pobrać wszystkie build-dep oprócz czekania na ich instalację w chroot.

werdykt: buduj z dystansu. Buforowanie kompilacji jest świetnym ustawieniem domyślnym, a pbuild jest wystarczająco inteligentny, aby wykryć, czy w archiwum jest nowsza wersja kompilacji i w razie potrzeby ściągnie nową wersję. W przypadku złożonego pakietu z wieloma wersjami kompilacji to proste ustawienie pozwoli Ci zaoszczędzić minuty życia.

Podsumowanie

Po wyjęciu z pudełka uważam, że skrypty pbuilder są znacznie bardziej przyjazne i szybsze niż ich odpowiedniki. Oczywiście istnieją sposoby, aby pbuilder był jeszcze szybszy (budowanie w tmpfs, wyłączanie niektórych haków chroot), i prawdopodobnie są też takie same sztuczki dla sbuilda, ale nie jestem ich świadomy.

Mam nadzieję że to pomoże.