De naam van het broncodepakket te weten komen¶

    % dpkg -S /lib/i386-linux-gnu/libc.so.6 
    libc6:i386: /lib/i386-linux-gnu/libc.so.6
    % dpkg -s libc6:i386
    Package (Pakket): libc6
    Status (Toestand): install ok installed (geienstalleerd)
    ...
    Source (Bron): glibc

(In dit voorbeeld is libc6 een pakket van het type "multi-arch: allowed", hetgeen betekent dat het voorkomt in verschillende andere vormen/compilaties voor verschillende architecturen. Daarvandaan komt ":i386".)

De Debian-release (de "suite") te weten komen¶

Indien u niet weet met welke suite u werkt, kunt u het volgende gebruiken:

    % grep '^deb' /etc/apt/sources.list
    deb http://the.earth.li/debian/ jessie main non-free contrib
    ...
    %

Voor Debian moet u aan het eind van de naam van de suite ",-security" toevoegen, tenzij u met de suite unstable of testing werkt. Dus in ons voorbeeld wordt "jessie" "jessie,-security". (Wel degelijk met de komma.)

Welke takken er zijn¶

Voor elke release (zoals "jessie") bestaat een meelopende tak voor de inhoud van het archief, genoemd "remotes/dgit/dgit/jessie" (en net zo voor andere suites). Deze kan bijgewerkt worden met "dgit fetch jessie". Deze, de "remote" suitetak, wordt samengesteld door uw lokale kopie van dgit. Een lineaire veranderingsgeschiedenis wordt opgebouwd (N.v.d.V.: fast forwarding in git-terminologie).

De veiligheidsupdates worden door Debian afgezonderd in "*-security". Aan dgit de opdracht "jessie,-security" geven, betekent dat het de eventueel in "jessie-security" aanwezige updates moet opnemen. De notatie met de komma houdt de vraag aan dgit in om jessie op te volgen of jessie-security als zich daarin een update voor het pakket bevindt.

(U kunt ook het commando dgit fetch gebruiken in een mappenboom die niet door git clone aangemaakt werd. Indien daarin geen "debian/changelog" aanwezig is, zult u met dgit fetch de optie "-p"pakket moeten gebruiken.)

Welk soort broncodeboom u verkrijgt¶

De metagegevens van Debian over het pakket en de scripts voor het bouwen van de binaire pakketten bevinden zich in "debian/". Aanknopingspunten zijn "debian/control", "debian/changelog" en "debian/rules". In het beleidshandboek van Debian vindt u meestal de nodige diepgaande technische informatie.

Bij veel Debian-pakketten zijn ook zaken te vinden in "debian/patches/". U kunt deze best negeren. Voor zover deze relevant zijn, zullen deze toegepast zijn in de eigenlijke bestanden, vermoedelijk via feitelijke commentaren in de git-geschiedenis. Wanneer binaire pakketten gebouwd worden vanuit met dgit verkregen git-takken, wordt de inhoud van debian/patches genegeerd.

(Voor Debian-ingewijden: de git-boomstructuren die met dgit verkregen worden zijn "verpakkingstakken met toegepaste patches, maar zonder .pc-map".)

Welk soort geschiedenis u verkrijgt¶

Maar van veel pakketten bestaat geen echte git-geschiedenis of werd die niet in een dgit-achtige vorm gepubliceerd. Het is dus mogelijk dat u vaststelt dat de geschiedenis eerder kort is en door dgit bedacht.

dgit-geschiedenissen bevatten vaak automatisch gegenereerde vastleggingen (commits), met inbegrip van vastleggingen die geen wijzigingen aanbrengen, maar enkel dienen om een zich herintegrerende aftakking in te passen in de lineaire vorm van de veranderingsgeschiedenis (N.v.d.V.: "make a rebasing branch fast-forward" in git-terminologie). Dit is in het bijzonder het geval bij gecombineerde takken zoals "jessie,-security".

Indien de pakketonderhouder gebruik maakt van git, dan kunt u na een dgit clone een handig "vcs-git" remote opmerken, wat verwijst naar het git-archief waarvan de pakketonderhouder gebruik maakt voor het pakket. U kunt zien wat zich daar bevindt met "git fetch vcs-git". Maar gebruik wat u daar vindt met zorg: de git-archieven van onderhouders van Debian bevatten vaak zaken die erg verwarrend en zonderling kunnen zijn. In het bijzonder zult u mogelijk handmatig de patches moeten toepassen die zich in debian/patches bevinden voor u iets anders doet!

Leg steeds veranderingen vast (N.v.d.V.: "commit" in git-terminologie) voor u begint te bouwen¶

    % wget 'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250;mbox=yes;msg=89' | patch -p1 -u
    % git commit -a -m 'Reparatie van libc-bug waarbij verlies van uitvoer optreedt'

Het bouwproces van een Debian-pakket verloopt vaak erg rommelig: het kan bestanden wijzigen die ook vastgelegd zijn in git of uitvoer en tijdelijke bestanden achterlaten die niet door ".gitignore" afgedekt zijn.

Indien u steeds een vastlegging doet, kunt u gebruik maken van

    % git clean -xdf
    % git reset --hard

om na het bouwproces een opruimactie te doen. (Indien u vergat vast te leggen, gebruik dan deze commando's niet; in de plaats kunt u misschien "git add -p" gebruiken om te helpen vastleggen wat u werkelijk wenst te bewaren.)

Dit zijn verwoestende commando's die alle nieuwe bestanden wissen (dus moet u eraan denken om "git add") uit te voeren) en elke aanpassing aan een bestand weggooien (u moet er dus aan denken om een vastlegging uit te voeren).

Werk het bestand changelog (minstens eenmaal) bij voor u bouwt¶

    % gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit

De binaire pakketten welke u bouwt zullen een versienummer hebben dat uiteindelijk afkomstig is uit het bestand "debian/changelog". U wilt toch uw binaire pakketten kunnen onderscheiden van die van uw distributie.

En dus moet u "debian/changelog" bijwerken en er bovenaan een item toevoegen voor u de bouw uitvoert.

Deze rune geeft een makkelijke manier om dit te doen. Het voegt een nieuw item toe aan changelog met een niet-informatieve mededeling en een plausibel versienummer (dat een stukje van het id van uw vastlegging bevat).

Indien u een meer gesofisticeerde manier wilt, biedt het pakket "dpkg-dev-el" een goede Emacs-modus voor het bewerken van changelogs. U kunt anders de changelog ook bewerken met een andere teksteditor, of "dch" of "gbp dch" uitvoeren met verschillende opties. Het kiezen van een goed versienummer is een beetje een netelige kwestie en een volledige behandeling van dit onderwerp valt buiten het bestek van deze handleiding.

Het eigenlijke bouwen¶

    % mk-build-deps --root-cmd=sudo --install
    % dpkg-buildpackage -uc -b

dpkg-buildpackage is het belangrijkste gereedschap voor het bouwen van een Debian-broncodepakket. "-uc" betekent: geen pgp-ondertekening toevoegen aan de resultaten. "-b" betekent: alle binaire pakketten bouwen, maar geen broncodepakket.

Gebruik maken van sbuild¶

    % git clean -xdf
    % sbuild -c jessie -A --no-clean-source \
             --dpkg-source-opts='-Zgzip -z1 --format=1.0 -sn'

Merk op dat dit een "broncodepakket" (.dsc en .tar.gz) lijkt achter te laten in de bovenliggende map, maar u moet dit broncodepakket niet gebruiken. Waarschijnlijk is het defect. Zie voor bijkomende informatie Debian-bug #868527.

Debian Jessie of eerder¶

    % sudo dpkg -i ../libc6_*.deb

U kunt "dpkg -i" gebruiken om de .deb-bestanden te installeren die uit uw pakket voortkwamen.

Indien de vereisten niet geienstalleerd zijn, zult u een foutmelding krijgen die gewoonlijk gerepareerd kan worden met "apt-get -f install".

Debian Stretch of later¶

    % sudo apt install ../libc6_*.deb

Broncodepakketten¶

Indien een git-tak niet voldoende is en u een broncodepakket moet aanleveren, maar het formaat/de indeling ervan niet van belang is (bijvoorbeeld omdat u bepaalde software heeft die met broncodepakketten werkt en niet met git-geschiedenissen), kunt u deze methode gebruiken om een broncodepakket van het type "3.0 (native)" te genereren. Dit is niet meer dan een tar-archief met een bijhorend .dsc-metadatabestand:

    % echo '3.0 (native)' >debian/source/format
    % git commit -m 'overgang naar de broncode-indeling native' debian/source/format
    % dgit -wgf build-source

Indien u een goed ogend broncodepakket moet aanleveren, dan zult u bereid moeten zijn er heel wat meer werk in te investeren. U zult heel wat meer moeten lezen, misschien te beginnen bij dgit-nmu-simple(7), dgit-sponsorship(7) of dgit-maint-*(7)