Kapitel 15. Skapa ett Debian-paket

Det är ganska vanligt för en administratör som har hanterat Debian-paket på vanligt sätt att till slut känna behovet av att skapa sina egna paket, eller att modifier att existerande paket. Detta kapitel ämnar att besvara de vanligaste frågorna inom detta område, och tillhandahålla de element som krävs för att dra nytta av Debian-infrastrukturen på bästa möjliga sätt. Med lite tur, efter att ha provat på lokala paket, kan du till och med känna att du måste komma vidare och gå med i Debian-projektet i sig!

15.1. Bygg om ett paket från dess källkod

Att bygga om ett binärpaket krävs under flera olika omständigheter. I visa fall behöver administratören en programvarufunktion somkräver att programvaran kompileras från källkod, med en viss kompileringsflagga; i andra fall är programvara som paketerats och installerats av Debian inte uppdaterad. I det senare fallet kommer administratören vanligtvis bygga paketet från en senare version av Debian — så som Testing eller till och med Unstable — så att detta nya paket fungerar i deras distribution Stable; denna åtgärd kallas ”bakportering”. Som vanligt ska man innan åtar sig en sådan uppgift kontrollera om det redan har gjorts — en snabb kontroll av i Debian Package Tracker för det paketet kan avslöja den informationen.

→ https://tracker.debian.org/

15.1.1. Hämta källkoden

Rebuilding a Debian package starts with getting its source code. The easiest way is to use the apt-get source package-name command. This command requires a deb-src line in the /etc/apt/sources.list file, and up-to-date index files (i.e. apt-get update). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see Avsnitt 6.1, ”Att fylla i filen sources.list”). Note, however, that you will be downloading the source packages from the Debian version mentioned in the deb-src line.

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. Att göra ändringar

Låt oss använda samba paketet som exempel.

$ 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

The last command invokes a text editor (sensible-editor — this should be your favorite editor if it is mentioned in the VISUAL or EDITOR environment variables, and the default editor otherwise) to allow documenting the differences brought by this rebuild. This editor shows us that dch really did change the debian/changelog file.

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).

Beroende på de lokala ändringarna till paketen kan en uppdatering också krävas i filen debian/control, vilken innehåller en beskrivning av de genererade paketen. I synnerhet innehåller denna filen Build-Depends-rade som styr listan av beroenden som måste vara uppfyllda då paketet byggs. Dessa refererar ofta till versioner av paket som finns i distributionen som källkodspaketet kommer från men som kanske inte finns tillgängliga i distributionen som används för ombygget. Det finns inget automatiserat sätt att avgöra om ett beroenden är korrekt eller endast angivet för att garantera att man endast ska försöka sig på bygget med den senaste versionen av ett bibliotek — detta är det enda tillgängliga sättett att tvinga en autobyggare att använda en given paketversion under bygget, vilket är anledningen till att Debian-utvecklarna ofta använda strikt versionerade byggberoenden.

Om du är säker på att dessa byggberoenden är allt för strikta kan du känna dig fri att lösa upp dem lokalt. Att läsa filerna som dokumenterar standardsättet att bygga programvara — dessa filer kallas ofta INSTALL — kommer att hjälpa dig att lista ut lämpliga beroenden. I idealfallet borde alla beroenden kunna gå att tillfredställa från distributionen som används för ombygget; om inte inleds en rekursiv process där paket som nämns i fältet Build-Depends måste bakporteras innan målpaketet kan bakporteras. Vissa paket kanske inte kräver bakportering och kan installeras som de är under byggprocessen (ett exempel är debhelper). Notera att bakporteringsprocessen snabbt kan bli komplex om du inte är försiktig. Därför bör man försöka sig på bakportering endat då det är nödvändigt.

15.1.3. Starta ombyggnaden

When all the needed changes have been applied to the sources, we can start generating the actual binary package (.deb file). The whole process is managed by the dpkg-buildpackage command.

Exempel 15.1. Rebuilding a package

$ 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 QUICK LOOK Building packages in chrooted and virtual environments.

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.

VERKTYG fakeroot

In essence, the package creation process is a simple matter of gathering in an archive a set of existing (or built) files; most of the files will end up being owned by root in the archive. However, building the whole package under this user would imply increased risks; fortunately, this can be avoided with the fakeroot command. This tool can be used to run a program and give it the impression that it runs as root and creates files with arbitrary ownership and permissions. When the program creates the archive that will become the Debian package, it is tricked into creating an archive containing files marked as belonging to arbitrary owners, including root. This setup is so convenient that dpkg-buildpackage uses fakeroot by default when building packages.

Note that the program is only tricked into “believing” that it operates as a privileged account, and the process actually runs as the user running fakeroot program (and the files are actually created with that user's permissions). At no time does it actually get root privileges that it could abuse.

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.

QUICK LOOK Building packages in chrooted and virtual environments

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.

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 Avsnitt 12.2, ”Virtualisering” for an introduction into this topic.