Bez systemu pakowania mamy (A) kod źródłowy, który można przetłumaczyć/skompilować do (B) kodu binarnego.Jak pliki * .dsc są powiązane z plikami * .deb i plikami kodu źródłowego
W przypadku systemu Debian/Ubuntu mamy (1) kod źródłowy, (2) opakowanie źródłowy - DSC plików i (3) opakowania binarny - deb plików. Jak to jest (2) pakiet źródłowy związany z (1) i (3)? Dlaczego tego potrzebujemy? I najważniejsze pytanie: jaki jest przepływ pracy (2) i (3) z (1)?
Workflow zazwyczaj idzie w przybliżeniu tak:
Ktoś na Debianie pobiera Kod źródłowy i zapisuje
zbiór plików łat, aby zbudować źródło na Debianie i zgodne z wytycznymi Debiana. Uruchom
curl -s 'http://archive.ubuntu.com/ubuntu/pool/universe/s/splint/splint_3.1.2.dfsg1-2.diff.gz' | gunzip -dc | less
, aby zobaczyć ten przykład dla pakietu.
.dsc i plik debian/control. "DSC" jest akronimem Debian Source Control..deb są budowane dla każdej architektury z oryginalnego źródłowego kodu źródłowego z zastosowanymi łatami specyficznymi dla Debiana. Here is one such file. Debian Binary Package Building HOWTO wyjaśnia format tych plików i sposób ich sprawdzania.Plik .dsc nie jest używany do logiki kompilacji, bardziej do metadanych. Jednak wiele narzędzi po drodze tego wymaga. Na przykład pole Build-Depends: służy do instalowania wymaganych zależności kompilacji.
Jest to znacznie bardziej skomplikowane. Ideą pakietów Debiana jest to, że zawierają one wszystkie informacje potrzebne do zbudowania strony. Zwykle źródło jest modyfikowane tak, aby zawierało katalog debian, który zawiera plik control opisujący zależności tego pakietu i innych pakietów, z którymi współdziała (np. Przerwy, zastępuje, zapewnia pakiet wirtualny). Plik rules wyjaśnia, w jaki sposób zbudować i zainstalować pakiet. Istnieją również opisy dotyczące pakowania, ponieważ pakiet pojedynczego źródła może stać się wieloma pakietami binarnymi (np. foo-utils, libfoo0, libfoo-dev). debuild faktycznie odczytuje tę informację, wykonuje kompilację i tworzy pakiety binarne. Subtelność: jeśli foo używa libbar-dev, może nie wiem/jakiej wersji pakietu binarnego używam libbar. pbuilder działa debuild w czystym środowisku, więc nie ma szansy na kompilację w stosunku do rzeczy, które nie zostały wyraźnie określone.
Aby uzyskać szczegółowe informacje, zapoznaj się z Debian New Maintainers' Guide.
Dzięki za odpowiedź. Do tej pory używałem debiutu, ale mówisz, że zamiast tego powinienem użyć pbuildera? Co to są pakiety źródłowe? Nie są używane?Link, który ci opublikujesz, jest świetny, ale rozmiar mnie przeraził czytając :) –
pbuilder to wygodne narzędzie do sprawdzania, czy zależności są w pełni określone. Zasadniczo tworzy wirtualne środowisko bez niczego oprócz zadeklarowanych zależności; jeśli nie może ukończyć kompilacji, często oznacza to, że masz niezadeklarowaną zależność. Ale jeśli jesteś zainteresowany tworzeniem pliku '.deb' tu i teraz, nie musisz mieć tej ścisłości. – tripleee
Pakiet źródłowy to zdebianizowane źródło, tj. W zasadzie plik .orig.tar.gz plus twoje debdiffy. To jest to, co musisz dostarczyć innym, którzy chcą utworzyć plik .deb dla siebie, być może z własnymi łatkami lub poprawkami, lub może chcą zbudować pakiet dla innej architektury. Jeśli chcesz dostarczyć to innym, 'pbuilder' może zacząć mieć sens. – tripleee
Świetna odpowiedź! Jeszcze jedno pytanie. W przykładzie podanym tutaj mamy oryginalny kod (upstream) i diff po zmianach opiekuna. Kiedy nowa wersja oryginalnego kodu zostanie "zdebianizowana", jak opiekunowie będą śledzić zmiany? Łączą różnice między poprzednią wersją deb a nową wersją kodu źródłowego? Czy używali jakiegoś CVS? –
Po wydaniu nowej wersji zwykle po prostu ponownie zastosują łatki w starym '.diff.gz'. Jeśli coś się zepsuje, zaczną kopać. Niektórzy opiekunowie mogą używać 'git' lub' quilt' lub innych narzędzi, o których nie wiem, ale o ile wiem, naprawdę zależy to od opiekuna pakietu. – andrewdotn
Niektóre z linków w Twojej odpowiedzi są zepsute. –