Kapittel 15. Hvordan lage en Debian-pakke

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.

→ https://tracker.debian.org/

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.

VERKTØY fakeroot

I hovedsak er prosessen med å bygge pakker en så enkel sak som, i et arkiv, å samle et sett av eksisterende (eller bygde) filer. De fleste filene vil så bli eid av rot i arkivet. Men å bygge hele pakken under denne brukeren skulle tilsi økt risiko. Heldigvis kan dette unngås med fakeroot-kommandoen. Dette verktøyet kan brukes til å kjøre et program, og gi inntrykk av at det kjører som root, og skaper filer med vilkårlig eierskap og rettigheter. Når programmet skaper arkivet som vil bli Debian-pakken, er det lurt å skape et arkiv som inneholder filer merket som tilhørende vilkårlige eiere, inkludert rot. Dette oppsettet er så praktisk at dpkg-buildpackage bruker fakeroot som standard ved pakkebygging.

Merk at programmet bare er lurt til å «tro» at det fungerer som en priviligert konto, og prosessen faktisk kjører som om brukeren kjører fakeroot program (og filene faktisk er opprettet med den brukerens tillatelser). Ikke på noe tidspunkt får det faktisk rotprivilegier som det kunne misbruke.

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.

RASK TITT Bygging av pakker i chrooted og virtuelle omgivelser

Building a package on an existing system, like a workstation or server, can pose several problems. Maybe the system has packages installed, that conflict with the build requirements. Or maybe it has packages (libraries, headers, etc.) installed, that the project to build is not supposed to use - e.g. from Testing, Unstable, or even from third parties. Also it might have packages installed, which are actually required for the build, but are not listed in debian/control. It is therefore a good practice to build a packages in “clean“ environments.

The sbuild, pbuilder, or cowbuilder programs (in the similarly named packages) allow building a Debian package in a chrooted environment. Each of them first creates a temporary directory containing the minimal system required for building the package (including the packages mentioned in the Build-Depends field). This directory is then used as the root directory (/), using the chroot command, during the build process.

These tools allow the build process to happen in an environment that is not altered by users' manipulations. This also allows for quick detection of the missing build-dependencies (since the build will fail unless the appropriate dependencies are documented). Finally, it allows building a package for a Debian version that is not the one used by the system as a whole: the machine can be using Stable for its normal workload, and the chrooted environments can be running on the same machine using Unstable for package builds. Using these tools, it is also possible to build for a different distribution, like Ubuntu.

schroot, sbuild-shell, or pbuilder allow running a command or a login shell in a chrooted environment.

Sometimes it is not enough to build a package in a chrooted environment. This can be due to building for a different architecture where cross-compilation does not work, or due to the tools not being able to create a chrooted environment for the desired target system. Then one can create virtual machines to build the package there. These setups are usually more complex then the tools mentioned above, and rarely needed, so we will only mention this possibility without going into much detail. Check out Seksjon 12.2, «Virtualisering» for an introduction into this topic.