Product SiteDocumentation Site

فصل 15. إنشاء حزمة دبيان

15.1. إعادة بناء حزمة من المصدر
15.1.1. الحصول على المصادر
15.1.2. إجراء التغييرات
15.1.3. بدء إعادة البناء
15.2. بناء حزمتك الأولى
15.2.1. الحزم الفوقية أو الحزم الزائفة
15.2.2. أرشيف ملفات بسيط
15.3. إنشاء مستودع حزم للأداة APT
15.4. كيف تصبح مشرف حزم
15.4.1. تعلم إنشاء الحزم
15.4.2. عملية القبول
من الشائع جداً، بين مديري النظم الذين يتعاملون مع حزم جبيان بشكل منتظم، أن يصلوا إلى مرحلة يحتاجون فيها لإنشاء حزم خاصة بهم، أو لتعديل حزمة سابقة. يهدف هذا الفصل للإجابة عن أكثر الأسئلة شيوعاً في هذا المجال، وتقديم العناصر اللازمة للاستفادة من بنية دبيان التحتية بأفضل طريقة ممكنة. ومع بعض الحظ، قد تشعر ‒بعد تجربة مهاراتك في الحزم المحلية‒ بالحاجة للغوص أكثر من ذلك وتنضم لمشروع دبيان نفسه!

15.1. إعادة بناء حزمة من المصدر

Rebuilding a binary package is required under several sets of circumstances. In some cases, the administrator needs a software feature that requires the software to be compiled from sources, with a particular compilation option; in others, the software as packaged in the installed version of Debian is not recent enough. In the latter case, the administrator will usually build a more recent package taken from a newer version of Debian — such as Testing or even Unstable — so that this new package works in their Stable distribution; this operation is called “backporting”. As usual, care should be taken, before undertaking such a task, to check whether it has been done already — a quick look on the Debian Package Tracker for that package will reveal that information.

15.1.1. الحصول على المصادر

Rebuilding a Debian package starts with getting its source code. The easiest way is to use the apt-get source 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.compcomp 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 extracts the source package (unless the -d or --download-only option is used).

15.1.2. إجراء التغييرات

The source of the package is now available in a directory named after the source package and its version (for instance, samba-4.1.17+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.1.17+dfsg-2, we can create version 2:4.1.17+dfsg-2falcot1, 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, with an command such as dch --local falcot. This 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 …) 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 for explanations on how to achieve this).
قد تحتاج تحديث الملف debian/control أيضاً اعتماداً على طبيعة التغييرات المحلية التي أجريتها على الحزمة، يحوي هذا الملف وصفاً للحزم المولّدة. على وجه الخصوص، يحوي هذا الملف سطور Build-Depends تتحكم بقائمة الاعتماديات التي يجب تلبيتها عند بناء الحزمة. تشير هذه الاعتماديات غالباً إلى نسخ الحزم الموجودة في التوزيعة التي أتت منها الحزمة المصدرية، لكنها قد لا تكون متوفرة في التوزيعة المستخدمة للبناء. لا توجد طريقة مؤتمتة تبيّن هل الاعتمادية حقيقية أم أنها محددة فقط لضمان محاولة البناء باستخدام آخر نسخة من المكتبة — هذه هي الطريقة الوحيدة المتاحة لإجبار البانيات الآلية (autobuilder) على استخدام نسخة معينة من الحزمة أثناء البناء، لذلك يستخدم مشرفو دبيان في كثير من الأحيان اعتماديات لها أرقام محددة.
إذا كنت متأكداً أن هذه الاعتماديات صارمة أكثر من اللازم، يمكنك تخفيفها محلياً. ستساعدك قراءة الملفات التي توثق الطريقة المعيارية لبناء البرنامج — هذه الملفات تدعى INSTALL غالباً — على معرفة الاعتماديات المناسبة. في الحالة المثالية، يجب أن تتمكن من تلبية الاعتماديات ضمن التوزيعة المستخدمة للبناء؛ إذا لم تتمكن من ذلك، ستبدأ عملية تعاودية، حيث يجب نقل الحزم المذكورة في الحقل Build-Depends خلفاً قبل أن تتمكن من نقل الحزمة المستهدفة. قد لا تحتاج بعض الحزم أن تنقلها خلفياً، ويمكن تثبيتها كما هي أثناء عملية البناء (إحدى الأمثلة البارزة هي debhelper). لاحظ أن عملية النقل الخلفي قد تتعقد سريعاً إذا لم تكن حذراً. لذلك، يجب تقليل المنقولات الخلفية إلى أقل ما يمكن.

15.1.3. بدء إعادة البناء

بعد تطبيق كل التغييرات التي تحتاجها إلى الكود المصدري، يمكننا توليد الحزمة الثنائية (ملف .deb). يدير الأمر dpkg-buildpackage العملية كلها.

مثال 15.1. إعادة بناء حزمة

$ dpkg-buildpackage -us -uc
[...]
قد يفشل الأمر السابق إذا لم تُحدَّث حقول Build-Depends، أو إذا لم تُثبَّت الحزم المناسبة. في هذه الحالات، يمكن تجاوز عملية التحقق عبر تمرير الخيار -d إلى dpkg-buildpackage. لكن تجاهل هذه الاعتماديات صراحة يعرضك لخطر إخفاق عملية البناء في مرحلة لاحقة. وأسوأ من ذلك، قد يبدو أن الحزمة تبنى بشكل صحيح لكنها لا تعمل بشكل سليم لاحقاً: فبعض البرامج تعطّل بعض مزاياها آلياً إذا لم تعثر على إحدى المكتبات المطلوبة أثناء البناء.
في معظم الأحيان، يستخدم مطورو دبيان برنامجاً عالي المستوى مثل debuild؛ الذي يستدعي dpkg-buildpackage كالعادة لكنه يضيف أيضاً استدعاءً لبرنامج يجري عدة فحوصات للتحقق من اتفاق الحزم المولّدة مع سياسة دبيان. كما يُنظِّف هذا السكربت البيئة بحيث لا ”تُلوّث“ متغيرات البيئة المحلية عملية بناء الحزمة. الأمر debuild هو أحد الأدوات من المجموعة devscripts، التي تتناسق مع بعضها وتشترك في بعض الإعدادات حتى تسهِّل مهمة مشرف الحزمة.