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 har som mål å 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 selv bli med i Debian-prosjektet!

15.1. Ombygging av pakke 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 «tilbakeføring». 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 å sjekke om pakken kan vise info 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 (for eksempel 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.

If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions *.dsc — for Debian Source Control — *.tar.comp, and sometimes *.diff.gz or *.debian.tar.comp — comp taking one value among gz, bz2 or xz depending on the compression tool in use), then run the dpkg-source -x file.dsc command. If the *.dsc file is directly accessible at a given URL, there is an even simpler way to fetch it all, with dget URL. This command (which can be found in the devscripts package) fetches the *.dsc file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it verifies the integrity of the downloaded source packages using dscverify, and it extracts the source package (unless the -d or --download-only option is used). The Debian keyring is needed, unless the option -u is supplied.

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 -b bookworm
Please use:
git clone https://salsa.debian.org/samba-team/samba.git -b bookworm
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 18.5 MB of source archives.
Get:1 http://deb.debian.org/debian bookworm/main samba 2:4.17.12+dfsg-0+deb12u1 (dsc) [4,466 B]
Get:2 http://deb.debian.org/debian bookworm/main samba 2:4.17.12+dfsg-0+deb12u1 (tar) [18.2 MB]
Get:3 http://deb.debian.org/debian bookworm/main samba 2:4.17.12+dfsg-0+deb12u1 (diff) [273 kB]
Fetched 18.5 MB in 0s (59.1 MB/s)
dpkg-source: info: extracting samba in samba-4.17.12+dfsg
dpkg-source: info: unpacking samba_4.17.12+dfsg.orig.tar.xz
dpkg-source: info: unpacking samba_4.17.12+dfsg-0+deb12u1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying libsmbclient-ensure-lfs-221618.patch
dpkg-source: info: applying hurd-compat.patch
dpkg-source: info: applying [...]

The source of the package is now available in a directory named after the source package and its version (samba-4.17.12+dfsg); this is where we'll work on our local changes.

The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is 2:4.17.12+dfsg-0+deb12u1, we can create version 2:4.17.12+dfsg-0+deb12u1+falcot1, which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the dch command (Debian CHangelog) from the devscripts package.

$ cd samba-4.17.12+dfsg
$ 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.

Når det kreves en endring i oppbyggingen, må det lages endringer i debian/rules, som skritt for skritt driver pakkens byggeprosess. I de enkleste tilfellene er linjene om det opprinnelige oppsettet (./configure …), eller i det aktuelle bygget ($(MAKE) …, eller make … eller cmake … eller …) enkle å finne. Hvis disse kommandoene ikke påkalles eksplisitt, er de sannsynligvis en bivirkning av en annen eksplisitt kommando, i så fall kan du se i dokumentasjonen for å lære mer om hvordan du endrer forvalgt virkemåte. For pakker som bruker dh kan du trenge å legge til en overstyring for dh_auto_configure, eller dh_auto_build-kommandoene (sjekk de respektive manualsidene deres og debhelper(7) for forklaringer på hvordan du oppnår dette).

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, står du fritt til å gjøre dem mindre strenge 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å «tilbakeføres» før pakken som er målet for operasjonen kan bli det. Noen pakker trenger kanskje ikke tilbakeføring, og kan installeres som de er i løpet av byggeprosessen (et kjent eksempel er debhelper). Merk at tilbakeføringsprosessen raskt kan bli komplisert hvis du ikke er forsiktig. Derfor bør tilbakeføring 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
[...]

Forrige kommando kan mislykkes hvis Build-Depends-feltet ikke har blitt oppdatert, eller hvis de relaterte pakkene ikke er installert. I dette tilfellet er det mulig å overprøve denne sjekken ved å sende -d-argumentet til dpkg-buildpackage. Men å eksplisitt ignorere disse avhengigheter gir risiko for at byggeprosessen mislykkes på et senere tidspunkt. Verre; pakken kan se ut til å bygges korrekt, men klarer ikke å kjøre skikkelig: Noen programmer deaktiverer automatisk noen av sine egenskaper når et nødvendig bibliotek ikke er tilgjengelig på byggetidspunktet. Argumentet kan fremdeles være nyttig hvis du kun vil opprette en kildepakke, som er ment å sendes til et rene byggmiljø, som beskrevet i RASK TITT Bygging av pakker i chrooted og virtuelle omgivelser.

The other options used in the above example make sure that neither the source package's .dsc (-us) nor the produced .changes file (-uc) get signed with the package builder's cryptographic key after a successful build.

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.

I de fleste tilfeller bruker Debian-utviklere et høynivå-program som debuild. Dette kjører dpkg-buildpackage til vanlig, men legger også til en påkalling til et program som kjører mange kontroller for å validere den genererte pakken opp mot Debians retningslinjer. Dette skriptet renser også opp i miljøet, slik at lokale miljøvariabler ikke «forurenser» pakkebyggingen. Kommandoen debuild er et av verktøyene i devscripts-pakken, som deler noe konsistens og oppsett for å gjøre vedlikeholderens oppgave enklere.

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 packages in “clean“ environments.

Programmene sbuild, pbuilder, eller cowbuilder (i pakkene med tilsvarende navn) tillater bygging av en Debian-pakke i en chroot-omgivelse. Hver av dem lager først en midlertidig katalog med det minimale systemet som kreves for å bygge pakken (inkludert pakkene nevnt i Build-Depends-feltet). Denne katalogen blir så brukt som rotkatalog (/), og bruker chroot-kommandoen under byggeprosessen.

Disse verktøyene gjør at byggeprosessen skjer i et miljø som ikke påvirkes av det brukerne gjør. Dette gir også mulighet for å rask oppdage manglende byggeavhengigheter (i og med at byggingen vil feile med mindre de korrekte avhengighetene er ført opp). Og ikke minst, så kan en bygge en pakke for en Debian-versjon som ikke er den som brukes av systemet som helhet. Maskinen kan bruke Stable i sitt normale arbeid, og sine chroot-omgivelser som kjører på den samme maskinen, kan bruke Unstable til pakkebygging. Ved å bruke disse verktøyene blir det også mulig å bygge for en annen distribusjon, som Ubuntu.

schroot, sbuild-shell, eller pbuilder tillater kjøring av en kommando eller et innloggingsskall i et chroot-et miljø.

Noen ganger er det ikke nok å bygge en pakke i en chroot-omgivelse. Dette kan være fordi en bygger en annen arkitektur der kryss-kompilering ikke virker, eller som følge av at verktøyene ikke er i stand til å opprette chroot-omgivelse for ønsket målsystem. Da kan man i stedet opprette virtuelle maskiner for å bygge pakken der. Disse oppsettene er vanligvis mer komplekse enn bruk av verktøyene nevnt over, og sjeldent nødvendig. Denne muligheten nevnes uten å gå i detalj. Sjekk Seksjon 12.2, «Virtualisering» for en introduksjon i emnet.