Анализи, оценки, предложения

Малко по-задълбочени сравнения и анализи има в Advanced Package Management Comparisons.

Debian/GNU Linux: The Past, the Present and the Future -- presented at the Free Software Symposium 2002 on October 22, 2002 15:30 at the University of Tokyo.

Като, че ли е пропуснато да се обясни малко повече за работа с debian source packages (FIXME: да се обясни още по-подробно):

• уникални инструменти като auto-apt, различни проверки с dh_*, като dh_shlibdeps, или направо проверете какво съдържат пакетите dpkg-dev и debhelper, разгледайте сорса и документацията на съответните програми, идващи с тях.
• създаване на local apt repository, и подаване на custom build options глобално или поотделно за пакет (DEB_BUILD_OPTIONS, apt-build, apt-src, chrooted builds с pbuilder). Това са все важни неща, като се има предвид, че потребителя в общия случай ще иска (или му се налага) да има пакети с различни версии на дистрибуцията към момента. Може да са нужни и доста по-стари версии на пакети от http://snapshot.debian.net, както и следене на последните версии на всичко (за Debian това е Sid архива или пък project/experimental. Това не винаги е разумно решение, като освен това може да е добавено и local repository или въобще unofficial repositories, т.е. контролира се процеса на build от началото до края. Например auto-apt помага за:
  • откриването на липсващи хедъри и библиотеки, необходими за компилацията, свързването и намирането им в кой(и) пакет(и) са и предложение за инсталиране
  • подаване или установяване на custom build options
  • различни проверки с dh_*, особено проверка за коректност на получения binary package, в който най-вероятно ще има програми, които ще ползват поделени библиотеки (soname check и Debian Library Packaging guide
  Подобен контрол е необходим и ми се струва уникален Debian при builds, за да не бъде build процеса "`чуплив"', т.е. да прекъсва поради липси на това и онова, особено когато се предприема в смесена среда (напр. пакети от няколко издания на дистрибуцията). Трябва да има гаранции, че така полученото binary ще работи коректно. Ако има синтактични и/или логически програмни грешки в кода на приложението, естествено, че или вие трябва да ги оправите, или разработчиците. Така че е необходимо да има гъвкавост и потребителят да разполага с инструменти бързо и лесно да установява докъде се простира тя и от къде нататък започват да че чупят нещата и защо. Разбира се, това не пречи в /usr/local/ да водите война, инсталирайки каквото ви дойде на ума, без да разваляте нещата system-wide, пък може да пипате и там, ако се чувствате сигурни, че знаете какво правите.

Нова система за build на пакети се готви от Colin Walters. Тя се нарича версия 2 на source пакетите и в нея се адресират сложността на сегашните debian/rules файлове, както и многото излишък в тях. Новата система е силно повлияна от u-os пакетната система на Christoph Lameter. Основната идея е да се направят нещата прости, a сложните неща -- възможни.

В тази връзка доста се спекулира с т.н. source-based distributions, като Gentoo, при които софтуерът се компилира направо на машината на потребителя. Естествено, това може да стане и с debian source packages, въпреки че малко потребители го знаят;-). Основната идея е, че така могат да се използват по-добре оптимизациите на компилатора за съответния процесор. В това има доза истина, обаче се отнася само до т.н. CPU-intensive приложения като аудио и видео плеъри, библиотеки в които са реализирани някакви тежки математически или криптографски алгоритми, въобще програми, които могат да се възползват от конкретните за дадения процесор инструкции. Може да се окаже дори, че разликата между процесорите от x86 архитектурата не е забележима, докато при процесорите от Sparc архитектурата например едно такова оптимизиране дава сериозно отражение върху производителността. Затова не е лошо някои CPU-intensive приложения да се прекомпилират на място и да се оптимизират от source packages, ebuilds, ports и т.н., но да се очаква, че всички приложения ще се възползват от едно такова оптимизиране, е меко казано несериозно. Тук са замесени възможностите на съответното CPU, възможностите на съответния компилатор да оптимизира за него, както и самият на приложениетоу което се опитваме да оптимизираме. Ако последното е много зле, то никакъв компилатор и оптимизатор не може да ви помогне, затова най-добре се оптимизаира от изходния код на самото приложение. Ето едно сравнение на Debian за i386, Mandrake за i586 и Gentoo. Или с казано накратко, подобни оптимизации са определящи от гледана точка на производителността в много специфични случаи и не е казано, че само source-based distros могат да компилират своите пакети на потребителската машина. Debian предлага впечатляващо много инструменти по въпроса, като доста от тях са разгледани в предните глави на тази книга.

Вече като малко по-напреднали трябва да четете:

• Maint Guide или стария превод на български
• Debian Developer's Reference
• Debian Policy Manual
• и въобще Debian Developers' Corner