Product SiteDocumentation Site

Kapittel 15. Hvordan lage en Debian-pakke

15.1. Å bygge en pakke på nytt fra kildekoden
15.1.1. Henting av kildekode
15.1.2. Hvordan gjøre endringer
15.1.3. Å starte gjenoppbyggingen
15.2. Å bygge din første pakke
15.2.1. Meta-pakker eller falske pakker
15.2.2. Et enkelt filarkiv
15.3. Å lage en pakkebrønn for APT
15.4. Å bli en pakkevedlikeholder
15.4.1. Å lære å lage pakker
15.4.2. Aksepteringsprosess
Det er nokså vanlig for en administrator som har håndtert Debian-pakker jevnlig å etter hvert ønske å lage egne pakker, eller modifisere en eksisterende pakke. Dette kapittelet tar sikte på å svare på de vanligste spørsmålene på dette området, og gi nødvendige instrukser for å utnytte Debians infrastruktur på beste måte. Med litt flaks, etter å ha prøvd deg fram med lokale pakker, kan du kanskje til og med tenke deg å gå lengre, og bli med i Debian-prosjektet selv!

15.1. Å bygge en pakke på nytt fra kildekoden

Å bygge en binær pakke på nytt er nødvendig under flere omstendigheter. I noen tilfeller trenger administratoren en programvarefunksjon som krever at programvaren som skal kompileres fra kildekoden med et spesielt kompileringsalternativ; i andre er programvaren som er pakket i den installerte versjonen av Debian ikke ny nok. I det sistnevnte tilfellet vil administratoren vanligvis bygge en nyere pakke tatt fra en nyere versjon av Debian - så som Testing, eller til og med Unstable - slik at denne nye pakken virker i deres Stable-distribusjon: Denne operasjonen kalles «backporting». Som vanlig bør man være forsiktig før en tar på seg en slik oppgave, og først sjekke om den har blitt gjort allerede: Ta en rask titt på Debians pakkesporer for å se om pakken kan vise informasjon om det.

15.1.1. Henting av kildekode

Å gjenoppbygge en Debian-pakke starter med å hente kildekoden. Den enkleste måten er å bruke kommandoen apt-get source pakkenavn. Slik bruk krever en deb-src-linje i filen /etc/apt/sources.list, og en oppdatert oversikt over pakkebrønnsfiler (f.eks. ved bruk av apt-get update). Disse forutsetningene bør allerede være på plass hvis du har fulgt instruksen i kapitlet som har med APT-oppsett å gjøre (sjekk Seksjon 6.1, «Innfylling av sources.list-filen»). Merk at du laster ned kildepakkene fra Debian-versjonen nevnt ideb-src-linjen.
Hvis du trenger en annen versjon, må du kanskje laste den ned manuelt fra et Debian-speil, eller fra nettstedet. Dette innebærer henting av to eller tre filer (med utvidelser *.dsc - for Debian Source Control - *.tar.comp, og noen ganger *.diff.gz eller *.debian.tar.comp - comp som tar en verdi blant gz, bz2 eller xz, avhengig av kompresjonsverktøyet som ble bruk), kjør deretter dpkg-source -x file.dsc-kommandoen. Hvis *.dsc-filen er tilgjengelig direkte fra en gitt URL, er det til og med enklere vei å få tak i alt sammen, med dget URL-kommandoen. Denne kommandoen (som er en del av pakke devscripts) fanger opp *.dsc-filen på den gitte adressen, så analyserer den innholdet, og filen eller filene det refereres til hentes automatisk. Når alt er lastet ned, verifiseres integriteten til den nedlastede kildekoden ved å bruke dscverify, og det pakker ut kildekoden (om ikke -d eller --download-only-valget er benyttet). Debian nøkkelring behøves om ikke valget -u foreligger.

15.1.2. Hvordan gjøre endringer

La oss bruke samba-pakken som et eksempel.
$ apt source samba
Reading package lists... Done
NOTICE: 'samba' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/samba-team/samba.git
Please use:
git clone https://salsa.debian.org/samba-team/samba.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 12.3 MB of source archives.
Get:1 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B]
Get:2 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB]
Get:3 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB]
Fetched 12.3 MB in 3s (4,582 kB/s)
dpkg-source: info: extracting samba in samba-4.13.13+dfsg
dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz
dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 07_private_lib
dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch
dpkg-source: info: applying [...]
Pakkekilden er tilgjengelig i en katalog oppkalt etter kildepakkens versjon (samba-4.13.13+dfsg): Dette er der vi skal jobbe med våre lokale endringer.
Det første du må gjøre er å endre pakkens versjonsnummer, slik at de nye pakkene kan skilles fra de opprinnelige pakkene som følger med Debian. Forutsatt at gjeldende versjon er 2:4.13.13+dfsg-1~deb11u3, kan vi lage versjon 2:4.13.13+dfsg-1~deb11u3falcot1, som tydelig viser opprinnelsen av pakken. Dette gjør pakkens versjonsnummer høyere enn den som tilbys av Debian, slik at pakken lett vil installeres som en oppdatering til den opprinnelige pakken. En slik endring er best utført med dch-kommandoen (Debian CHangelog) fra devscripts-pakken.
$ cd 4.13.13+dfsg-1~deb11u3
$ dch --local +falcot
Den siste kommandoen kaller et tekstredigeringsprogram (sensible-editor — dette bør være ditt favoritt-tekstredigeringsprogram hvis det er nevnt i VISUAL eller EDITOR-miljøvariablene, og forvalgt tekstredigeringsprogram ellers) for å tillate dokumentering av forskjellene som er forårsaket av denne gjenoppbyggingen. Dette skriveprogrammet viser oss at dch virkelig har endret debian/changelog-filen.
When a change in build options is required, the changes need to be made in debian/rules, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …) or the actual build ($(MAKE) … or make … or cmake … or …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh, you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages and debhelper(7) for explanations on how to achieve this).
Avhengig av de lokale endringene i pakkene, kan en oppdatering også være nødvendig i debian/control-filen, som inneholder en beskrivelse av de genererte pakker. Spesielt inneholder denne filen Build-Depends-linjer som kontrollerer listen over avhengigheter som må være oppfylt når pakken bygges. Disse refererer ofte til versjonene til pakkene i distribusjonen som kildepakken kommer fra, men som kanskje ikke er tilgjengelig i distribusjonen som brukes til ombygging. Det er ingen automatisk måte å avgjøre om en avhengighet er ekte, eller bare spesifisert til å garantere at bygget kun skal bli forsøkt med den nyeste versjonen av et bibliotek - dette er den eneste tilgjengelige måten å tvinge en autobuilder til å bruke en gitt pakkeversjon under oppbyggingen, og det er derfor Debians vedlikeholdere ofte bruker strenge versjonsbestemte byggeavhengigheter.
Hvis du vet sikkert at disse byggeavhengigheter er for strenge, bør du føle deg fri til å løsne på dem lokalt. Å lese filene som dokumenterer den vanlige måten å bygge programvare på - disse filene blir ofte kalt INSTALL - vil hjelpe deg å finne de riktige avhengighetene. Ideelt sett bør alle avhengigheter være imøtekommet fra distribusjonen som brukes til ombygging. Hvis de ikke er det, starter en gjentakingsprosess, der pakkene nevnt i Build-Depends-feltet må «backportes» («tilbakeporting») før målet pakken kan bli det. Noen pakker trenger kanskje ikke tilbakeporting, og kan installeres som de er i løpet av byggeprosessen (et kjent eksempel er debhelper). Merk at tilbakeportingsprosessen raskt kan bli komplisert hvis du ikke er forsiktig. Derfor bør tilbakeporting holdes på et absolutt minimum der det er mulig.

15.1.3. Å starte gjenoppbyggingen

Når alle de nødvendige endringene har blitt brukt på kildene, kan vi starte å generere den aktuelle binære pakkefilen (.deb). Hele prosessen er håndtert av dpkg-buildpackage-kommandoen.

Eksempel 15.1. Å bygge om en pakke

$ dpkg-buildpackage -us -uc
[...]
The previous command can fail if the Build-Depends field has not been updated, or if the related packages are not installed. In such a case, it is possible to overrule this check by passing the -d option to dpkg-buildpackage. However, explicitly ignoring these dependencies runs the risk of the build process failing at a later stage. Worse, the package may seem to build correctly but fail to run properly: some programs automatically disable some of their features when a required library is not available at build time. The switch can still be very useful if you only want to create a source package, which is supposed to be passed to clean build environments as described in RASK TITT Bygging av pakker i chrooted og virtuelle omgivelser.
De andre valgene i eksempelet ovenfor sørger for at hverken kildepakkens .dsc (-us) og ei heller resulterende .changes-fil (-uc) signeres med pakkebyggerens kryptografiske nøkkel etter at bygget fullføres på riktig vis.
More often than not, Debian developers use a higher-level program such as debuild; this runs dpkg-buildpackage as usual, but it also adds an invocation of a program that runs many checks to validate the generated package against the Debian policy. This script also cleans up the environment so that local environment variables do not “pollute” the package build. The debuild command is one of the tools in the devscripts suite, which share some consistency and configuration to make the maintainers' task easier.