تحتاج إعادة بناء حزمة ثنائية في عدد من الظروف. في بعض الحالات، يحتاج مدير النظام ميزة برمجية تتطلب ترجمة البرنامج من المصدر، مع استخدام خيار ترجمة معين؛ وفي حالات أخرى، لا يكون البرنامج المُحزَّم في النسخة المُبّتة من دبيان حديثاً بما يكفي. في الحالة الأخيرة، سيعمد مدير النظام عادة لبناء حزمة جديدة مأخوذة من نسخة دبيان أحدث — مثل
الاختبارية أو حتى
غير المستقرة — بحيث تعمل هذه الحزمة الجديدة في توزيعته
المستقرة؛ تدعى هذه العملية ”بالنقل الخلفي“ (backporting). كالعادة، عليك الانتباه، قبل أن تجري هذه المهمة، إلى التحقق من أن أحداً لم يسبقك إليها — نظرة سريعة على صفحة متتبع حزم دبيان الخاصة بتلك الحزمة ستعطيك هذه المعلومة.
15.1.1. الحصول على المصادر
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
قسم 6.1, “تعبئة الملف 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 the dget URL
command. 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.
Let us use the samba package as an example.
$
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 [...]
The source of the package is now available in a directory named after the source package and its version (samba-4.13.13+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.13.13+dfsg-1~deb11u3
, we can create version
2:4.13.13+dfsg-1~deb11u3+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 4.13.13+dfsg-1~deb11u3
$
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).
قد تحتاج تحديث الملف debian/control
أيضاً اعتماداً على طبيعة التغييرات المحلية التي أجريتها على الحزمة، يحوي هذا الملف وصفاً للحزم المولّدة. على وجه الخصوص، يحوي هذا الملف سطور Build-Depends
تتحكم بقائمة الاعتماديات التي يجب تلبيتها عند بناء الحزمة. تشير هذه الاعتماديات غالباً إلى نسخ الحزم الموجودة في التوزيعة التي أتت منها الحزمة المصدرية، لكنها قد لا تكون متوفرة في التوزيعة المستخدمة للبناء. لا توجد طريقة مؤتمتة تبيّن هل الاعتمادية حقيقية أم أنها محددة فقط لضمان محاولة البناء باستخدام آخر نسخة من المكتبة — هذه هي الطريقة الوحيدة المتاحة لإجبار البانيات الآلية (autobuilder) على استخدام نسخة معينة من الحزمة أثناء البناء، لذلك يستخدم مشرفو دبيان في كثير من الأحيان اعتماديات لها أرقام محددة.
إذا كنت متأكداً أن هذه الاعتماديات صارمة أكثر من اللازم، يمكنك تخفيفها محلياً. ستساعدك قراءة الملفات التي توثق الطريقة المعيارية لبناء البرنامج — هذه الملفات تدعى INSTALL
غالباً — على معرفة الاعتماديات المناسبة. في الحالة المثالية، يجب أن تتمكن من تلبية الاعتماديات ضمن التوزيعة المستخدمة للبناء؛ إذا لم تتمكن من ذلك، ستبدأ عملية تعاودية، حيث يجب نقل الحزم المذكورة في الحقل Build-Depends
خلفاً قبل أن تتمكن من نقل الحزمة المستهدفة. قد لا تحتاج بعض الحزم أن تنقلها خلفياً، ويمكن تثبيتها كما هي أثناء عملية البناء (إحدى الأمثلة البارزة هي debhelper). لاحظ أن عملية النقل الخلفي قد تتعقد سريعاً إذا لم تكن حذراً. لذلك، يجب تقليل المنقولات الخلفية إلى أقل ما يمكن.
بعد تطبيق كل التغييرات التي تحتاجها إلى الكود المصدري، يمكننا توليد الحزمة الثنائية (ملف .deb
). يدير الأمر dpkg-buildpackage
العملية كلها.
مثال 15.1. إعادة بناء حزمة
$
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 the asuccessful build.
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.