الموضوع ملتقط من رد الأستاذ مؤيد السعدي في صفحة المجتمع على الفيس بوك عن مقارنة بين جوانب القوة والضعف في نظام تحزيم دبيان و فيدورا

نظام apt
ليس transactional
يعني المفروض أن يكون النظام إما في وضعية الحزم القديمة أو وضعية الحزم الجديدة
يجب أن لا يكون في حالة وسط النظام مكسور لا طال عنب الشام ولا بلح اليمن
يجب أن يتتبع مدير الحزم هذه العمليات ويتحقق من سلامتها قبل أن تبدأ
وأن يتمكن من التراجع عنها
أبت لا يفعل ذلك
بل يبدأ بالعمل ثم يكتشف في وسط العملية أن هناك شيء ما خطأ ويخرج والنظام مدمر
مثلا لنفرض أن مدير الحزم أبت يريد تحديث مجموعة من الحزم فقام بتحديث مكتبة كذا
ثم بدأ بتحديث شيء وتبين أنه يتعارض مع شيء ما فخرج وترك النظام مكسور دون تحديث البرامج الباقية
تخيل معي لو أن مكتبة كذا الحديثة
غير متوافقة مع القديمة
المفروض أن يكون النظام في وضعية برامج قديمة مع مكتبة قديمة
او وضعية مكتبة حديثة وبرامج حديثة
لكن نص نص تعني أن البرامج لا تعمل
تخيل أن تكون تلك البرامج التي لا تعمل من ضمنها أدوات اصلاح المشكلة

طريقة تأمين حزم ديبيان التفافية ولا تحقق الممارسات الفضلى
حزم ديبيان لا تحتوي تواقيع الكترونية مضمنة فيها
لذا لو اعطيتك ملف اسمه
Checkme.deb
فإنك لا تستطيع التحقق من هويته وسلامة محتوياته من العب

حزم rpm
هي الحزم الوحيدة المعترف بها وفق معايير lsb
وبناءها يتم عبر ملف تصريحي
Declarative
عياري يسمى spec file
ويمكن تمحيصه عبر أداة rpmlint
بالمقابل لا يمكن تمحييص تحزيم حزم deb
بطريقة آلية
لأنه مجموعة من السكربتات غير العيارية الأمرية
Imperative
لا يمكن التحقق من تطبيق الممارسات الفضلى بشكل آلي في حزم ديبيان
ولا يمكن أن تفتح حزمة وتفهمها لأنها open ended
بالمقابل حتى تفهم spec
تحتاج تعلم حفنة صغيرة عيارية
وليست ذات نهاية مفتوحة

نظام حزم deb / apt
نظام تفاعلي
يحتاج أن أحيانا لتشغيل واجهة رسومية لعمل deb conf
وهذا مخالف للأتمتة ويحتاج عدة طرق احتيالية
وأيضا هذا من السهل ان يؤدي لكارثة
مثلا لنتخيل أنني أمرت الخادم تطبيق تحديثات فوجد تحديث للخطوط وتحديث أمني
وكان تحديث الخطوط يشغل debconf
فإن نظام debconf
عرقل وصول التحديث الأمني بانتظار تفاعلك مع الواجهة
واذا انقطع الاتصال مع الخادوم في هذه اللحظة سيترك النظام مكسور

أغبى طريقو لتدمير نظام يعمل ب apt
هي أن تكتب
ما سيحصل هو أن المتخلف debconf
سيقوم بمحاولة تشغيل الاثنين في منتصف ال transaction
مخلفا نظاما مكسورا
لماذا لأنه سيحاول تشغيلهما كلاهما وكلاهما يحجزان نفس المنفذ
هذا مخالف للممارسات الفضلى لأنه لا يجوز تشغيل خدمة قبل ان أقوم بمراجعة إعداداتها
كيف يفتح منفذ وأنا لم أنته من تأمينه فأنا كنت أنوي أن أضيف عليه كلمة سر basic auth
وكنت انوي تشغيل اباتشي على منفذ 8080
و nginx
على 80
لكن هذا المتخلف شغلهما معا بشكل متضارب
وليس هذا فحسب بل إنه فعل ذلك في منتصف ال transaction
ليس قبله ولا بعد اكتماله
مما جعله يترك النظام مكسورا

هناك معايير
إن dnf و yum و Zypper و
وغيرها تستعمل نفس المستودعات ونفس الحزم
يعني توفر vendor independent
و interoperability
يعني مثلا dnf
هو أكثرها feature complete
ويدعم runtime plugins
مكتوبة بايثون
لكن لست ملزما به بل يمكنك استعمال أي مدير حزم يحقق نفس المعايير مثل microdnf
لكنه مصغر
او tdnf
من شركة vmware
وهو مكتوس بلغة سي بدل بايثون
Drop in replacement
Vendor independent
هذه أشياء مهمة.

يبدو أرتش pacman
لا يحتوي تواقيع على المعلومات الفوقية
https://archived.forum.manjaro.org/....pacman.../1481