Subsections

Local APT Repositories

Създаване и управление на локално apt-хранилище с готови deb-файлове

Ако разполагате с .deb-файлове в някоя локална директория, за да ги инсталирате, единият от начините е да се изпълни dpkg -i по реда на зависимостите, което може да бъде и досадно. За това ще е по-културно да се впрегне apt да свърши това вместо нас.

debuild: debian binary пакети от source пакети

В пакета devscripts ще намерите една много полезна Perl програма наречена debuild(1). Използва се за получаване на debian binary packages (deb-файлове) от debian source packages:

# debuild -b -uc -us

sbuild: debian binary пакети от source пакети

За разлика от debuild програмката от едноимения пакет sbuild разбира и от source dependencies.

cvs-buildpackage: debian binary пакети от CVS хранилище

Управлява build процеса за получаване на deb пакет от сорсове съхранявани в произволно CVS хранилище (да не си помисли някой, че сорса трябва да е на cvs.debian.org;-). Много яка утилка.

apt-build: Инсталиране на пакети от сорс

Накратко

Колкото и странно да звучи на някои, ако искате да имате винаги възможно най-актуалните версии на софтуера за GUN/Linux, най-лесният път към това е използването на Debian. Противно на общоприетото схващане, тази дистрибуция се снабдява най-пъргаво с всички нови програми и ви предоставя достатъчно гъвав и лесен начин за тяхното управление с помощта на серия инструменти.

Добре е известно, че Debian се дели на три -- да ги наречем условно -- издания: stable, testing и unstable (има и project/experimental, но там нещата са наистина за експерименти). В stable влиза проверен от времето (и хакерите) софтуер, на който можете да разчитате за сериозни задачи, изискващи максимална сигурност и стабилност. Логично е, софтуерът в stable да е по-старичък. Официалните ISO-имиджи на stable можете да изтеглите от Интернет и с тяхна помощ да си направите една базова инсталация, която впоследствие да надградите и актуализирате до testing, където влизат по-нови неща, подлежащи на усилено тестване и кандидати за stable, или направо да преминете към unstable, където буквално има всичко, което е излязло на бял свят към момента. Имате и друга възможност: част от пакетите да държите от stable (например, ядрото, базовата система), а друга част, която е по-клиентски ориентирана (като KDE и GNOME), да вземете от unstable. Много хора се оплакват, че Debian stable е толкова стар, че дори се инсталира с ядро 2.2.x. Така е по подразбиране, но ако четат внимателно, ще видят, че инсталацията на Debian предлага широк набор от ядра, между които и 2.4.х. В този текст няма да се занимаваме с основните команди на програмата apt-get(8), с които би трябвало да е запознат всеки любител на тази дистрибуция, а ще обърнем внимание на един друг инструмент -- apt-build(1). С негова помощ можете напълно автоматизирано да си направите собствено apt-хранилище (или local apt repository), смисълът от което е познат на всеки почитател на сорс-базираните дистрибуции. Ползата от подобно хранилище е огромна: избирате компилатор по собствено желание и опции за оптимизация също по свой вкус, като така постигате максимална производителност за цялата система, управлявате хранилището със стотиците компилирани от вас пакети с apt-get(8), подобно на всеки друг дебиански източник. Като собственик на преклонно стар компютър, аз не мога да си позволя лукса, предоставян например от Gentoo, да компилирам от изходен код цялата си дистрибуция. А и това не е необходимо. Оставяме настрана ядрото, за което има специален инструмент kernel-package(5). Съсредоточаваме се само върху най-често използваните потребителски приложения, за да не губим излишно време в безкрайни компилации, като съобразяваме нуждите си с възможностите на самия компютър.

Какво е необходимо

Първо трябва да се уверим, че във файла, в който се описват източниците на дебианския софтуер, сме въвели и пътя към сорсовете. Би трябвало в /etc/apt/sources.list да виждаме нещо такова:

deb ftp://ftp.bg.debian.org/debian stable main contrib non-free
deb ftp://ftp.bg.debian.org/debian unstable main contrib non-free
deb http://security.debian.org/ stable/updates main
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ stable/updates main
deb-src http://security.debian.org/ testing/updates main
deb-src ftp://ftp.bg.debian.org/debian stable main contrib non-free
deb-src ftp://ftp.bg.debian.org/debian unstable main contrib non-free

След това, трябва да инсталираме apt-build:

# apt-get install apt-build

При самата инсталация ще бъдем попитани къде искаме да бъде създадена директорията, в която ще се съхраняват пакетите от нашето хранилище, кой компилатор предпочитаме (например, gcc-3.2), дали искаме да се прилагат някакви специални опции за оптимизация. По подразбиране директорията на нашето хранилище е /var/cache/apt-build/repository. Накрая ще бъдем попитани дали искаме въпросната директория да бъде описана във файла с дебиански източници, на което ние отговаряме утвърдително.

Създаване на собствени пакети с apt-build

Можете да се изненадате колко е просто, но всъщност цялата процедура се свежда до една единствена команда. Пакетите със сорсове носят същото наименование като бинарните. Да речем, че искате да си инсталирате последната версия на Mozilla.

# apt-build install mozilla-browser

Оттук нататък apt-build ще се погрижи да си изтегли и инсталира всички необходими за компилацията пакети, за да компилира успешно mozilla, ще съхрани новите бинарита в хранилището, откъдето ще ги инсталира и вие ще можете да ги управлявате вече по стандартния начин с apt-get(8).

Създаване на .deb пакети и добавяне в хранилището

Добре, няма нищо по-лесно от това да инсталирате от официалните източници на Debian пакети, като ги компилирате локално с apt-build(1). Но, да речем, че искаме да пипнем тук-там в сорса или да компилираме пакет, който не влиза никъде в Debian, след което ще го добавим в нашето хранилище. В първия случай можем да изтеглим само сорса с apt-get(8):

# apt-get source mozilla-browser

Можете да посочите и конктерна версия на сорса на пакета, например:

# apt-get source diff=2.8.1-6

където diff е името на пакета, а 2.8.1-6 е неговата версия. Общия формат на версията е: Epoch:UpstreamVersion-DebianPackageVersion или например texttt4:1.2.3-8. Epoch и DebianPackageVersion са опционални и не винаги се ползва. Наличните версии можете да намирате чрез:

# apt-cache policy package

Сорсът ще се изтегли и разархивира в текущата директория. Можем да направим каквото искаме по него и след това да го компилираме с dpkg-buildpackage(1). В резултат ще получим отново дебиански бинарита (deb-файлове), които можем да копираме в нашето хранилище. След като ги копираме, трябва да кажем на apt-build(1) да актулизира съдържанието на файловете Packages.gz и Sources.gz, от които чете пък apt-get(8), за да се ориентира къде какви пакети има.

# apt-build update-repository

Полезни процедури с apt-build

apt-src

FIXME: Съдържание трябва да има тука ;-)

pbuilder

FIXME: Съдържание трябва да има тука ;-)

apt-fu

Описание

deb http://www.yhbt.net/normalperson/debian ./
deb-src http://www.yhbt.net/normalperson/debian ./

kernel-package: Компилиране на ядро по дебиански

Накратко

По желание на потребителя ядрото може да бъде и като debian package, взет наготово от Debian archive-a или получен при потребителя, който освен изтегляне на kernel sources от където пожелае, четене на Documentation/Changes за евентуален upgrade на някои user space utils, като gcc, make, binutils и т.н., конфигуриране, компилиране и инсталиране както намери за добре, може да използва и kernel-package(5), предоставящ Perl scripts, чрез които може да се получи собствен (custom) debian kernel package(s) за kernel images и евентуално и kernel modules от upstream kernel sources (изтеглени напимер от kernel.org) или от debian packages като kernel-source-*, kernel-patch-*, kernel-image-*, kernel-headers-*. За повече подробности се обърнете към man kernel-package(5) или документацията в /usr/share/doc/kernel-package/, както и статията http://www.osnews.com/story.php?news_id=2949

Ето как се използва инструмента kernel-package(5), който е характерен за Debian GNU/Linux. Разбира се, първо инсталираме самия kernel-package(5) :

# apt-get install kernel-package

След като се инсталира, можете да въведете личните си данни в /etc/kernel-package.conf, така, че създаденият от вас .deb пакет с новото ядро ще носи информация за онзи, който го е създал (ставате maintainer:)). След като изтеглите сорса на ядрото и го компилирате и пакетирате в удобен за управление формат, можете да инсталирате новото ядрото по официалния за дистрибуцията начин, като по този начин го направя част от системата. Именно тези възможности предоставя инструментът kernel-package(5). Разбира се, това е един вариант, който е опционален, а не задължителен.

Основни процедури

В Debian можете да си инсталирате сорса на избраното от вас ядро, леко пачнат от авторите на дистрибуцията (т.е. добавена е директория debian/ с maintainer scripts, иначе сорса си е същия като upstream, или да си разпакетирате upstream архива от kernel.org, т.е. официалния изходен код. Да речем, че го вземем от архива на Debian:

# apt-get install kernel-source-x.x.x

В /usr/src ще се появи архивът със сорса, който вие трябва да разпакетирате. В резултат ще се появи нова директория /usr/src/kernel-source-x.x.x, към която е добре да създадете символна връзка:

# ln -s /usr/src/kernel-source-x.x.x /usr/src/linux
# cd /usr/src/linux

За нетърпеливите

Командата, с която можете да зададете комплексно цялата процедура по конфигурацията и компилацията, е следната:

# make-kpkg --config menuconfig kernel_image

Така, все едно сте изпълнили едновременно make menuconfig, make dep bzImage modules. След цялата процедура в /usr/src ще се появи .deb пакет с новото ядро, който можете да инсталирате по стандартния начин, а това ще ви спести и ровенето в /etc/lilo.conf, е разбира се, вие можете да погледнете все пак и в този файл какво е положението. Предишното ядро ще бъде описано със суфикса .old и ще можете да го заредите като резервен вариант, ако сте объркали настройките преди компилацията на новото ядро. В случай, че използвате initrd(4), ще трябва да добавите още опция към командата:

# make-kpkg --config menuconfig --initrd kernel_image

Внимание! Ако ползвате оригиналния сорс, преди цялата процедура трябва създадете стандартната директория debian/, без която автоматизацията е немислима.

# make-kpkg debian

Добра идея е да се инсталира и пакета kernel-tree-ВЕРСИЯ:

# apt-get install kernel-tree-2.6.9

което ще дръпне и kernel-source и kernel-patch-debian при което ще получим и промените направени от Debian kernel Team и можем да стартираме компилаията така:

make-kpkg --added-patches debian -rev mybuild.1 kernel_image

За любознателните

Самата процедура на изграждане на ядрото е следната:

  1. Редактира се файла .config, намиращ се в директорията със сорса на ядрото. Това може да се извърши по няколко начина:

  2. Следва компилирането и пакетирането. То може да бъде изпълнено с командата:
    # make-kpkg kernel-image
    

Ядрото и избраните от Вас модули ще бъдат компилирани и след това ще бъде изграден Debian пакет с име kernel-image-<версия>_<архитектура>.deb, който ще се появи в /usr/src/.

За повече информация относно конфигурирането на ядрото и значението на най-използваните и нужни опции, можете да погледнетe статията на Никола Антонов и съответните й части на адрес - http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=340742097.

Следва да инсталирате пакета с новото Ви, намиращ се в /usr/src:

# dpkg -i kernel-image-<версия>_<архитектура>.deb

Най-вероятно ще бъдете запитани дали искате да бъде направена boot дискета с новото ядро (не е проблем да откажете). Също тако, ако използвате LILO за зареждане на системата (подразбиращия се в Debian Woody), ще Ви се предложи да бъде направен нов запис според съществуващия вече /etc/lilo.conf. Не се притеснявайте да отговорите с "Yes", тъй като kernel-package(5) ще се погрижи новото ядро да бъде добавено в /etc/lilo.conf, а старото също така да е налично, в случай, че сте объркали нещо с конфигурацията на новото ядро и то откаже да зареди. Така при проблем можете да заредите старото (по подразбиране е именувано LinuxOLD) и пак да имате функционираща система.

Допълнителна информация

Освен описаните до тук основни функции на kernel-package(5), нужни за да компилирате набързо едно ядро, има и някои други тънкости. Информация за тях можете да намерите във файла /usr/share/kernel-package/README или като изпълните командата man make-kpkg(1). Също така можете да хвътлите един поглед на man kernel-img.conf(5) и man kernel-pkg.conf(5).

Също така можете да обърнете внимание на следните две неща:

  1. "Проблемът", който се получава при използването на автоматичната редакция на /etc/lilo.conf: при този метод скриптовете на kernel-package(5) се грижат /vmlinuz да сочи към най-новото ядро, а /vmlinuz.old към следващото по "новост". При система с повече от две компилирани ядра се получава така, че не са налични всички ядра в списъка на LILO за зареждане, а само последните две. Всеки индивидуално може да намери решение на "проблема" (било то да се направи друга символна връзка към по-старо ядро, което обезателно трябва да присъства в списъка на LILO освен най-новите, или нещо друго)

  2. Използването на опцията -append_to_version (разгледайте и -revision). Да речем, че имате сорса на ядро 2.4.18 и искате да компилирате няколко нови ядра от този сорс. Ако не се направят някакви промени, модулите на стари и нови ядра ще се озоват в една и съща директория (/lib/modules/2.4.18) и ще се получи бъркотия от различни модули. Едно от решенията на проблема е да се използва следната процедура за компилиране:

# make-kpkg clean
# make menuconfig
# rm -rf include/linux/version.h
# make-kpkg --append_to_version -1mykernel kernel_image

По този начин се избягва горепосоченият проблем, а новото ядро ще бъде именувано vmlinuz-2.4.18-1mykernel. Можете да сменяте стойността на -append_to_version при всяко компилиране, но трябва да се съобразявате с вече указаната процедура. Повече информация относно този проблем можете да намерите в съответните секции на /usr/share/kernel-package/README и man make-kpkg(1).

Инсталиране на драйвери за ALSA и NVidia с kernel-package

Нека да компилираме драйверите на NVidia и ALSA :

# apt-get install nvidia-glx-src nvidia-kernel-src alsa-source

Добре е да добавите в списъка и пакетите alsa-base (задължителен е!), alsa-utils и alsaconf (ако случайно притрябва). При инсталацията на пакета alsa-source ще бъдем попитани дали искаме да се компилират всички драйвери или само за конкертна звукова платка.

В /usr/src се появава една директория nvidia-glx-x.x.x, в която има само поддиректорията debian/ и нищо друго. Намираме и архив nvidia-kernel-src.tar.gz, който след като разархивираме, дава директория modules, в която сякаш също няма коя знае какво. Всъщност, това не са самите сорсове. Тези архиви съдържат само информацията, необходима за изтеглянето и компилирането на самите сорсове. А самите сорсове са все още на сървъра на NVidia. Те не могат да влязат в състава на дистрибуцията, защото конфликтират с DFSG. Не е така с архива alsa-driver.tar.gz. Той съдържа необходимите сорсове, който разархивираме, за да ги добави в /usr/src/modules.

Следва рутинната процедура:

# cd /usr/src/nvidia-glx-x.x.x
# dpkg-buildpackage -us -uc

Тази команда дава като резултат .deb пакет с glx модула на NVidia. Обърнете внимание как инсталиращия пакет ще се свърже със сървъра на NVidia, ще си изтегли сорса на модула и ще го компилира пред очите ви. Същото ще направи и с kernel драйвера.

# cd /usr/src/linux
# make-kpkg modules_image

Това е. След малко ще имате два .deb пакета с ALSA драйверите за избраната от вас звукова платка и с драйвера на NVidia. Инсталирате пакетите по стандартния начин и рестартирате системата или просто само скрипта /etc/init.d/modutils restart. Да, рестартирате. Не редактирате никакви конфигируцаионни файлове, не пипате /etc/modules и пр. -- за всичко това се е погрижил вече Debian.

Можете да конфигурирате драйверите за ALSA (ако вече това не е станало при инсталирането на пакета) с помощта на инструмента alsaconf(1), който подобно на sndconfig(1) за OSS просто редактира /etc/modules.conf по индиректен начин, чрез добавяне на информация в /etc/modutils. В Debian /etc/modules.conf се редактира от debconf, и не се препоръчва да се редактира от потребителя, освен ако наистина знае какво прави, за ръчни указания относно заежданите модули за ядото е предвиден /etc/modules. Но това вече е друга тема.

Само за NVidia остава задължителното и познато на всеки редактиране на /etc/X11/XF86Config-4. Там, все пак, kernel-package(5) няма власт:)



George Danchev 2004-12-25