[ назад ] [ Зміст ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ далі ]


APT HOWTO
Глава 5 - Побудова з джерельних пакунків


5.1 Завантаження джерельних пакунків

Звичайною річчю в світі вільного програмного забезпечення є вивчення джерельного коду чи, навіть, внесення виправлень в помилковий код. Щоб здійснити це, вам потрібно завантажити джерельні коди програми. Система APT пропонує простий метод отримання джерельного коду багатьох програм, що містяться в дистрибутиві, включаючи всі файли, потрібні для створення .deb-пакунку програми.

Іншим загальноприйнятим використанням джерельних пакунків Debian є адаптація більш свіжих версій програм, наприклад, зі збірки unstable, для використання в stable. Компіляція пакунка в середовищі stable згенерує .deb-файл з залежностями, пристосованими до доступних в цій збірці пакунків.

Для досягнення цього, запис deb-src в вашому /etc/apt/sources.list повинен вказувати на unstable і бути дозволеним (не закоментованим). Див. Файл /etc/apt/sources.list, розділ 3.1.

Aptitude, менеджер пакунків Debian переважно працює з двійковими пакунками. Натомість, для роботи з джерельними пакунками ви повинні використовувати програму apt-get. Щоб завантажити джерельний пакунок ви можете виконати:

     $ apt-get source packagename

При цьому завантажується три файла: .orig.tar.gz, .dsc та .diff.gz. Для пакунків, створених спеціально для Debian, останнього файлу немає, а в назві першого зазвичай відсутня вставка „orig“.

Файл .dsc використовується програмою dpkg-source для розпаковування джерельного пакунка в теку назва_пакунка-версія. Кожен завантажений джерельний пакунок має теку debian/, в якій знаходяться необхідні для створення .deb-пакунка файли.

Щоб після завантаження пакунок автоматично збирався, просто додайте -b до командного рядка, ось так:

     $ apt-get -b source packagename

Якщо ви вирішили не створювати .deb-файл одразу після завантаження, ви можете зробити це пізніше, виконавши команду

     $ dpkg-buildpackage -rfakeroot -uc -b

Зверніть увагу, що для побудови більшості пакунків вам знадобляться такі пакунки: devscripts, dpkg-dev, debhelper, fakeroot. Перегляньте Встановлення та перевстановлення пакунків, розділ 4.4 та встановіть передусім їх. Багато пакунків також залежать від інструментів компіляції, тому корисно також встановити пакунок build-essential. Можливо, знадобляться й інші пакунки,— щоб дізнатись про це більше, див. Пакунки, потрібні для компіляції джерельних пакунків, розділ 5.2.

Щоб встановити пакунок, збудований за допомогою наведених вище команд, потрібно використовувати менеджер пакунків напряму (див. Встановлення завантажених вручну або створених самостійно deb-пакунків, розділ 4.5). Пакунок devscripts надає вельми корисний інструмент: debi. Якщо ви запустите debi, знаходячись в початковій теці вашого джерельного пакунок, ця програма спочатку спробує знайти файл .changes в батьківській теці і, переглянувши його, дізнатись, які двійкові пакунки створюються, після чого запустить dpkg для їх встановлення. Однак, вочевидь, цей варіант є неприйнятним, якщо з вашого джерельного пакунка відбувається збірка декількох конфліктуючих між собою пакунків, як це часто трапляється. Звичайно, щоб здійснити всі ці дії вам потрібні права користувача root.

Існує відмінність між методом source та іншими методами apt-get. Метод source можуть використовувати звичайні користувачі, він не потребує спеціальних прав root. Файли завантажуються до теки, з якої викликається команда apt-get source package.


5.2 Пакунки, потрібні для компіляції джерельних пакунків

Зазвичай, для компіляції джерельного пакунка потрібні деякі заголовки та бібліотеки спільного користування. В усіх джерельних пакунках в файлі control є поле під назвою Build-Depends:, котре вказує, які додаткові пакунки потрібні для збірки джерельного. Також необхідні деякі базові пакунки, перегляньте Завантаження джерельних пакунків, розділ 5.1 перед тим, як рухатись далі.

З APT ці пакунки можна завантажувати дуже просто. Просто запустіть apt-get build-dep package, де package — це назва пакунка, який ви хочете зібрати. Наприклад:

     # apt-get build-dep gmc
     Reading Package Lists... Done
     Building Dependency Tree... Done
     The following NEW packages will be installed:
       comerr-dev e2fslibs-dev gdk-imlib-dev imlib-progs libgnome-dev libgnorba-dev
       libgpmg1-dev 
     0 packages upgraded, 7 newly installed, 0 to remove and 1  not upgraded.
     Need to get 1069kB of archives. After unpacking 3514kB will be used.
     Do you want to continue? [Y/n]

Пакунки, що будуть встановлені, потрібні для коректної збірки gmc. Важливо відмітити, що ця команда не завантажує джерельний пакунок програми, котру ви маєте компілювати. Для цього потрібно окремо запустити apt-get source.

Якщо вашою метою є лише перевірка того, які пакунки потрібні для збірки даного пакунка, ви можете, як варіант, використати команду apt-cache showpkg (див. Отримання інформації про пакунки, Глава 6), яка, серед іншої інформації, показує також список таких пакунків в рядку Build-Depends.

     # apt-cache showsrc пакунок

5.3 Створення пакунка для „зневаднення“ (debug)

Якщо ви хочете сформувати пакунок з метою його відлагодження — наприклад, для створення повідомлення про помилку або її виправлення, ви можете використати прості змінні середовища, які підтримуються в більшості з пакунків Debian.

Для побудови пакунка, що містить „не оголені“ двійкові файли [6] все що вам потрібно,— це дати команду на формування пакунка з префіксом DEB_BUILD_OPTIONS=nostrip. Крім цього, процес пошуку помилок може утруднити оптимізація, тому її варто вимкнути, додавши також до значень змінної DEB_BUILD_OPTIONS рядок noopt. Наприклад:

     $ DEB_BUILD_OPTIONS="nostrip noopt" dpkg-buildpackage -rfakeroot -uc -b

5.4 Перевизначення параметрів побудови пакунка

Якщо ви хочете дещо переінакшити спосіб збирання пакунка, вам доведеться зайнятись редагуванням файлу debian/rules. Тобто: увійдіть до головної теки, що була створена після того, як джерельний пакунок був видобутий з архіву — там ви знайдете підтеку debian, в якій знаходиться багато файлів . Один з них вирізняється — це файл rules.

Цей файл — звичайний Makefile, що має цілі для налаштування (configure), побудови (build), встановлення (install) та створення (create) пакунка. Наприклад, я хочу мати пакунок luola [7], побудований без підтримки звуку, для цього після завантаження та видобування відповідного джерельного пакунка потрібно відредагувати файл debian/rules, що виглядає приблизно так:

     [...]
     configure: configure-stamp
     configure-stamp:
     	dh_testdir
     	# Add here commands to configure the package.
     	./configure $(confflags) \
     		--prefix=/usr \
     		--mandir=share/man \
     		--infodir=share/info \
     		--datadir=share/games \
     		--bindir=games \
     		--enable-sound
     #		 --enable-sdl-gfx	
     
     	touch configure-stamp
     [...]

Бачите перемикач --enable-sound? Якщо я видалю його або заміню на --disable-sound і потім збудую пакунок заново (див. Завантаження джерельних пакунків, розділ 5.1), то матиму пакунок luola без підтримки звуку.

Якщо ви дійсно бажаєте працювати з джерельними пакунками щодня, то я пропоную вам прочитати для початку Довідник нового супроводжуючого Debian та Політику Debian. Також може стати в нагоді й інша документація, яку можна знайти в Куточку розробника Debian.


5.5 Але якщо я не хочу використовувати матеріали Debian?!

Іноді людина хоче використовувати специфічну версію програми, доступну лише у вигляді джерельних кодів, а не пакунку Debian. Але пакункова система може стати для цього певною перешкодою. Припустимо, ви хочете скомпілювати нову версію вашого серверу електронної пошти. Все б чудово, але багато пакунків в Debian залежать від MTA (Mail Transport Agent). Однак, оскільки ви встановили дещо самостійно вами скомпільоване, система керування пакунками не знатиме про його існування.

І тут на сцену виходить „equivs“. Щоб скористатись ним, встановіть однойменний пакунок. Equivs створює порожній пакунок з повним набором залежностей; робить так, щоб у системи керування пакунками склалось враження, що всі залежності задовольняються.

Перед тим, як ми почнемо, непогано було б нагадати вам, що є і більш безпечні шляхи компіляції з різноманітними параметрами тих програм, для котрих вже існують пакунки Debian, і що не потрібно використовувати equivs для заміни залежностей, якщо ви не не впевнені в тому, що робите. Щоб дізнатись більше перегляньте Завантаження джерельних пакунків, розділ 5.1.

Отже, повернемось до нашого прикладу з MTA. Ви щойно встановили ваш наново скомпільований postfix і переходите до встановлення mutt. Раптом виявляється, що mutt вимагає встановити інший MTA. Але у вас вже є ваш власний!

Перейдіть до якоїсь теки (наприклад, /tmp) і запустіть:

     # equivs-control name

Замініть name на назву керуючого (control) файлу, який ви хочете створити. Він буде мати такий вигляд:

     Section: misc
     Priority: optional
     Standards-Version: 3.5.10
      
     Package: <enter package name; defaults to equivs-dummy>
     Version: <enter version here; defaults to 1.0>
     Maintainer: Your Name <yourname@foo.com>
     Pre-Depends: <packages>
     Depends: <packages>
     Recommends: <packages>
     Suggests: <package>
     Provides: <(virtual)package>
     Architecture: all
     Copyright: <copyright file; defaults to GPL2>
     Changelog: <changelog file; defaults to a generic changelog>
     Readme: <README.Debian file; defaults to a generic one>
     Extra-Files: <additional files for the doc directory, commaseperated>
     Description: <short description; defaults to some wise words>
      long description and info
      .
      second paragraph

Нам просто потрібно привести його до потрібного нам вигляду. Погляньмо на формат полів і їх описи. Очевидно, немає потреби пояснювати кожне з них окремо, давайте натомість просто зробимо все, що потрібно:

     Section: misc
     Priority: optional
     Standards-Version: 3.0.1
     
     Package: mta-local
     Conflicts: mail-transport-agent
     Replaces: mail-transport-agent
     Provides: mail-transport-agent

Так, це все. mutt залежить від віртуального пакунка mail-transport-agent, котрий забезпечується будь-яким MTA, mta-local „реєструється“ як mail-transport-agent (агент транспортування пошти), використовуючи можливості поля Provides.

Поля Conflicts та Replaces потрібні для того, щоб APT та dpkg зрозуміли, що повинні видалити встановлений на даний момент пакунок MTA, якщо ви захочете встановити інший.

Тепер треба просто зібрати пакунок:

     # equivs-build name
     dh_testdir
     touch build-stamp
     dh_testdir
     dh_testroot
     dh_clean -k
     # Add here commands to install the package into debian/tmp.
     touch install-stamp
     dh_testdir
     dh_testroot
     dh_installdocs
     dh_installchangelogs
     dh_compress
     dh_fixperms
     dh_installdeb
     dh_gencontrol
     dh_md5sums
     dh_builddeb
     dpkg-deb: building package `name' in `../name_1.0_all.deb'.
     
     The package has been created.
     Attention, the package has been created in the current directory,

І встановити отриманий .deb-файл. Див. Встановлення завантажених вручну або створених самостійно deb-пакунків, розділ 4.5.

Як видно, equivs можна застосовувати по-різному. Наприклад, можна створити пакунок my-favorites, який буде залежати від програм, які ви зазвичай встановлюєте. Просто звільніть вашу уяву, але будьте обережними.

Важливо відзначити, що в теці /usr/share/doc/equivs/examples знаходяться приклади файлів control. Перегляньте їх.


[ назад ] [ Зміст ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ далі ]


APT HOWTO

2.0.2 - October 2006

Gustavo Noronha Silva kov@debian.org