Ръководство на новите отговорници по поддръжка на Debian Josip Rodin Превод: Николай Христов version 1.0, 25 January 2000. Copyright © 1998, 1999, 2000 Josip Rodin.

Този документ може да бъде използван съгласно GNU General Public License version 2 или по-голяма.

Този документ беше написан използвайки тези два документа като примерни:

Making a Debian Package (AKA the Debmake Manual), copyright © 1997 Jaldhar Vyas The New-Maintainer's Debian Packaging Howto, copyright © 1997 Will Lowe Начало "Правилният Начин"

Този документ ще се опита да опише изграждането на Debian GNU/Linux пакет на обикновения Debian потребител (и този който иска да стане разработчик) на разбираем език и добре допълнен с примери.

Едно от нещата което прави Debian добра дистрибуция е пакетната система. Въпреки че голяма част от софтуера може да се намери в Debian формат, все някога се налага да инсталирате нещо на което няма .deb пакет. Може би се чудите как може да си направите собствен .deb пакет и вероятно мислите, че е много трудно. Е, ако сте наистина нов в Linux, трудно е, но ако сте начинаещ предполагам няма да четете в момента този документ. :-). Трябва да знаете малко относно Unix програмирането но не се изисква да сте магьосник.

Най-новите версии на този документ могат да бъдат намерени винаги на адрес: и в `maint-guide' пакета. Програми нужни за разработка

Преди да започнете, уверете се че сте инсталирали допълнителните пакети нужни за разработка. Забележете, че списъкът не съдържа пакети маркирани като `essential' или `required - очакваме че вече ги имате инсталирани.

Този документ беше написан когато официалната стабилна дистрибуция на Debian беше 2.1 `slink' но не вярвам да срещнете затруднения ако имате =>2.2 `potato' защото пакетите са именувани почти по същия начин.

Следните пакети са инсталирани при стандартна инсталация на Debian 2.1, така че вероятно ги имате (и допълнителните пакети от които зависят) вече. Все пак по добре е да проверите чрез `dpkg -s <package>`. binutils - нужни за свързване на обектни файлове - с тях се правят програмите :). (виж `info binutils`) cpp - C предпроцесор. (виж ) cpio - това е архиватор като tar или zip. (виж ) dpkg-dev - този пакет съдържа инструменти които са нужни за разкомпресирането, изграждането и "качването" на Debian пакети с изходен код. (виж ) file - тази полезна програмка определя какъв вид е файла. (виж ) gcc - GNU C компилатор. Повечето от Linux програмите са написани на C. Ако вашата програма е написана на някой друг език като C++, Fortran, Pascal, трябва да инсталирате съответно g++, g77, или gpc . (виж , , , ) libc6-dev - C библиотеките и .h файловете които са нужни на gcc при компилирането. Въпреки че някой програми препоръчват да използвате libc5, чувствайте се насърчени да използвате по-новата версия (libc6). (виж `info libc`) make - обикновенно създаването на една програма преминава през няколко стъпки. Вместо да въвеждате едни и същи команди по няколко пъти може да ползвате тази програма за автоматизиране на този процес чрез `Makefile'-овете. Някои програми използват imake и xmkmf които генерират Makefile-ове на базата на макро функции. Повечето нови програми използват конфигуриращи скриптове създавани чрез програми като autoconf и automake, така че може би ще ви се наложи да инсталирате и тях. (виж `info make`, , , , ) patch - тази много полезна програма ще вземе файл който съдържа списък с различията (направен чрез програмата diff) и ще вмъкне промените в оригиналния файл. (виж ) perl5 - Perl е най-използвания скрипт език в днешните un*x системи, често наричан "Швейцарската резачка на Unix" :-). (виж )

От секцията `devel' вероятно ще се наложи сами да инсталирате следните неща: dh-make и debhelper - dh-make е нужен за създаването на скелета на нашия примерен пакет и той ще използва някои от инструментите на debhelper за създаване на пакетите. Те не са жизнено важни за създаването на пакетите, но силно се препоръчват за новите отговорници по поддръжка. Като цяло улеснява процеса на създаването и контролирането на пакета. (виж , , /usr/share/doc/debhelper/README) devscripts - този пакет съдържа полезни скриптове са за улеснение на отговорниците по поддръжка, но не са необходими за създаването на пакетите. (виж /usr/share/doc/devscripts/README.gz) fakeroot - тази програмка ви позволява да излъжете че сте root което е нужно за някои части от процеса на изграждане. (виж ) lintian - това е програма която проверява за грешки след като сте изградили вашият Debian пакет и ако има грешки дава подробна информация за тях. (виж , /usr/share/doc/lintian/lintian.html/index.html)

И накрая, следните много важни пакети са и тези от doc секцията: debian-policy - включва структурата и съдържанието на архива, няколко документа относно архитектурата на операционната система, стандарт за йерархия на файловата система (fhs, the Filesystem Hierarchy Standard) и най-важното за вас е описанието за изискваните неща които един пакет трябва да има за да бъде включен в дистрибуцията Debian.(виж /usr/share/doc/debian-policy/policy.html/index.html) developers-reference - за всичко онова, което не се отнася точно за техническите детайли по правенето на пакети, като напр. описание на структурата на архива, как да преименуваме, да изоставяме правилно пакети, които нямаме възможност повече да поддържаме, да поемем поддържането на даден пакет, да качваме (upload) правилно чужди пакети, как да подържаме съобщенията за грешки в пакетите ни, кога и къде да upload-ваме ... и т.н. (виж /usr/share/doc/developers-reference/developers-reference.html/index.html) packaging-manual - описва техническите аспекти на създаването на Debian binary и source пакети. (виж /usr/share/doc/packaging-manual/packaging.html/index.html)

Също така ще се нуждаете от пакет за шифроване като PGP (pgp-* пакетите) или GPG (gnupg пакетът), за да можете да подпишете вашите пакети. Това е важно ако искате да ги направите достъпни за всички (и сигурно точно това ще правите ако вашият труд бъде включен в Debian дистибуцията). Но поради доста странния U.S. закон няма да можете просто да свалите тези пакети от най-близкия огледален FTP сървър на Debian. Ще трябва да го направите от non-US.debian.org (ftp://non-us.debian.org/debian-non-US/) който се намира извън US. Във всеки FTP сървър има един файл наречен README.non-US, в който е указано как да намерите най-близкия за вас non-US огледален сайт.

Краткото описание дадено по-горе е само за да ви упъти кой пакет какво върши. Преди да продължите, моля прочетете доументацията за всяка от програмите. Може да ви се вижда доста трудно засега, но по-късно ще се радвате че сте ги прочели. Забележка: debmake е пакет който съдържа програми който действат по аналогичен начин на dh-make, но неговото използване не е разгледано в този документ. Вижте за повече информация. Друга информация

Има два типа пакети които може да правите - source и binary. Source пакетът съдържа изходния код който може да компилирате в програма. Binary пакетът съдържа просто компилираната програма. Не смесвайте термини като изходен код на програмата (source of the program) и изходен пакет на програмата! (source package of the program) Моля прочетете други документации ако имате нижда от повече детайли за терминологията.

В Debian терминът `maintainer' се използва за човек който прави пакети, `upstream author' за човек който поддържа програма извън Debian проекта. Обикновенно авторът и upstream maintainer са един и същ човек, а понякога и дори `maintainer' е същия човек. Ако сте направили програма и искате тя да бъде включена в Debian чувствайте се свободен да кандидатствате за maintainer.

След като сте изградили пакет (или докато го правите), трябва да станете официален Debian maintainer ако искате програмата да бъде включена в следващата дистибуция (ако програмата е полезна, защо не?). Този процес е обяснен в Ръководство на Разработчика. Моля прочетете го. Първи стъпки

Докато документацията в не е пределно ясна относно къде и как новите отговорници по поддръжка могат да започнат работата си, този документ ще обясни всяка малка (и може би на пръв поглед ненужна) стъпка и ще ви помогне да създадете първия си пакет и да придобиете някакъв опит за да моежете да изграждате следващи версии или може би други пакети по-късно. Изберете вашата програма.

Вероятно вече сте избрали пакет който искате да изградите, но има някои указания за вас като начинаещ: проверете дали пакетът не присъства вече в дистрибуцията. Ако ползвате 'стабилна'-та дистрибуция, може би е най-добре да погледнете на . Ако ползвате текущата `нестабилна' дистрибуция проверете с тези команди: dpkg -s програма dpkg -l '*програма*' консултирайте се с и с debian-devel mailing list архивите за да се уверите че никой не се занимава с поддръжката на същия пакет. Ако има вече отговорник по поддръжката пишете му ако смятате че е нужно. Ако не - намерете друга интересна програма която никой не поддържа. програмата трябва да има лиценз, по възможност да е свободен съгласно . Ако не съответства на някое от тези условия все още може да бъде включена в секциите `contrib' или `non-free'. Ако не сте сигурни в коя секция трябва да бъде включена, задайте въпрос на програмата непременно не трябва да бъде setuid root, или още по-добре - не трябва да изисква setuid или setgid. програмата не трябва да бъде демон или да се инсталира в */sbin директориите. програмата трябва да е изпълним файл, не пробвайте да пакетирате библиотеки все още. трябва да е добре документирана, или поне разбираема (за всеки). трябва да се свържете с автор(а/ите) на програмата за да проверите съгласни ли са тя да бъде пакетирана. Важно е да се свържете с автор(а/ите) на програмата в случай че възникнат специфични проблеми, така че не се опитвайте да пакетирате неподдържан софтуеър. и накрая но не на последно място трябва да се уверите че програмата работи и да сте я ползвали известно време.

Разбира се, тези неща са просто предпазни мерки и са с цел да ви спаси от ядосани потребители ако нещо сте объркали при setuid демон... Когато придобиете повече опит в пакетирането, ще имате възможностите да направите такъв пакет, но дори и най-опитните разработчици се консултират в debian-devel mailing list когато не са сигурни. И хората там с удоволствие ще ви помогнат.

За повече информация относно това, проверете в "Developer's Reference". Вземете програмата и я пробвайте.

Първото нещо което трябва да направите е да намерите и изтеглите оригиналния пакет. Предполагам че вече сте изтеглили изходния код на програмата. Изходния код на Linux програмите обикновенно са в tar/gzip формат, с разширение .tar.gz, и обикновенно съдържа поддиректория с име програма-версия с изходния код на програмата в нея. Ако изходният код е в някакъв друг тип архив (примерно името на файла завършва с Z" или".zip"), разархивирайте я със съответната програма или попитайте на debian-mentors ако не сте сигурни как да я разархивирате правилно (съвет: изпълнете `file archive.extension`).

За примера ще ползвам програмата наречена `gentoo' която е X11 GTK+ файлов мениджър. Забележете че програмата е вече пакетирана, и се е изменила от версията когато този документ е писан.

Създайте поддиректория във вашата потребителска директория именувана 'debian' или 'deb' или каквото име намирате за подходящо (например просто ~/gentoo/ ще свърши работа в този случай). Поставете изтегления архив в нея и го разархивирайте (ето така `tar xzf gentoo-0.9.12.tar.gz`). Уверете се че няма грешки, дори и такива които не се отнасят за този случай, защото най вероятно ще се появят проблеми при разархивирането на други системи чиито инструменти за разархивиране може или да пренебрегнат тези аномалии или не.

Вече имате друга поддиректория, наречена 'gentoo-0.9.12'. Влезте в нея и внимателно прочетете документацията. Обикновенно трябва да има файл наречен README*, INSTALL*, *.lsm или *.html. Трябва да намерите инструкции как правилно да компилирате и инсталирате програмата (най-вероятно ще прочетете че трябва да инсталирате програмата в директория /usr/local/bin; няма да правите точно това, но повече по въпроса ще разгледаме по-късно в ).

Процесът варира от програма до програма, но повечето модерни програми идват с `configure' скрипт който конфигурира изходния код в съответсвие с вашата система и се уверява че може да бъде компилиран на нея. След като бъдат конфигурирани (с `./configure`), програмите обикновенно се компилират с `make`. Някои от тях поддържат `make check`, което изпълнява включените в програмата самопроверки. Инсталацията в определените директории обикновенно става с `make install`.

Сега пробвайте да компилирате и стартирате вашата програма за да се уверите че тя работи добре и не разваля нещо друго при инсталирането си или при стартирането.

Също така обикновенно е включена поддръжката на `make uninstall` което премахва инсталираните файлове, изпълнете го и `make clean` (или по-добре `make distclean`) за да почистите директорията с изходния код. Нещата предшестващи `dh_make'

Трябва да започнете пакетирането с напълно чиста (недокосвана) директория с изходен код, или по друг начин казано с току що разархивиран изходен код.

За да бъде изграден пакета правилно трябва да направите оригиналното име на програмата с малки букви (ако вече не е) и трябва да преместите директорията с изходния код в <име_на_пакет>-<версия>.

Ако името на програмата се състои от повече от една дума, съберете ги в една дума или направете съкращение. Примерно, програмата "John's little editor for X" като пакет може да се именува johnledx, или jle4x, или каквото вие решите стига да е в разумни граници, примерно 20 символа.

Също така проверете за точната версия на програмата (да бъде включена във версията на пакета). Ако тази програма не е номерирана с версия от сорта X.Y.Z, ами е с някакъв тип дата спокойно може да ползвате датата като номер на версия, като сложите пред нея "0.0." (за всеки случай ако разработчиците един ден решът да пуснат версия примерно 1.0). Значи, ако датата е 19ти Декември, 1998, версията ще стане 0.0.19981219. Някой програми нямат версия и в този случай най-добре е да се свържете с разработчиците за да се разбере дали има някакъв друг метод за номериране на версиите. Стартиране на `dh_make'

Уверете се че сте в директорията на изходния код и напишете това:

dh_make -e your.maintainer@address -f ../gentoo-0.9.12.tar.gz

Разбира се, заместете "your.maintainer@address" с вашия e-mail адрес за да бъде включен в changelog и в други файлове и името на файла на оригиналния архив. Виж за повече информация.

Ще излезе известна информация. Ще бъдете попитан какъв тип пакет искате да създадете. Gentoo е пакет с един бинарен файл, също така и един .deb файл - така че избираме първата опция - `s' клавиша, проверете информацията на екрана и потвърдете като натиснете <enter>. Като нов maintainer препоръчително е да не създавате многобинарни пакети, или библиотеки, както е обяснено по-късно. Не е толкова трудно, наистина, но се изисква малко повече знания, така че няма да ги описваме всичките тук.

Забележете че dh_make трябва да бъде стартиран само веднъж , и няма да се държи коректно ако бъде стартиран отново във вече " дебианизирана" директория. Това означава че ще използвате друг метод за пакетиране на нови версии на вашия пакет за в бъдеще. Прочетете за това по-късно в Променяне на изходния код

Обикновенно, програмите се инсталират в /usr/local поддиректориите. Но Debian пакетите не трябва да използват тази директория тъй като тя е запазена за системно-администратоски (или потребителски) цели. Това означава че трябва да хвърлите едно око на системата за компилиране и инсталиране на програмата като обикновенно трябва да започнете с Makefile. Това е скрипта който ще използва за автоматичното изграждане на тази програма. За повече информация относно Makefile-овете, погледнете в .

Забележете, че ако вашата програма използва GNU и/или , тоест изходния код включва съответно Makefile.am и/или Makefile.in файлове ще трябва да направите промените в тях, защото всако извикване на automake ще презапише файловете Makefile.in с информация генерирана от Makefile.am, и всяко извикване на ./configure ще направи същото с Makefile-овете с данните от Makefile.in. Редактирането на Makefile.am файлове изисква известни познания относно automake за което може да прочетете тук: info automake, докато редактирането на Makefile.in файлове е почти същото като редактирането на Makefile-ове, само трябва да внимавате с променливите, тоест всеки низ заграден с `@', за пример @CFLAGS@ или @LN_S@, които се заменят с изстинските стойности при всяко извикване на ./configure.

Трябва да се отбележи че не можем да отделим място за всички детайли но ето няколко често срещани проблеми. Инсталиране в поддиректория

Повечето програми използват определен начин за да се инсталират в съществуващата структура на вашата система, така че файловете да бъдат включени във вашия $PATH и да може да намерите документацията и man страниците на обичайните места. Трябва да се уверите че това се прави коректно, но ще трябва да ги накарате да се инсталират във временна поддиректория която ще бъде създадена във вашата debian/ директория, която обикновенно е именувана debian/tmp от която инструментите за поддръжка ще изградят работещ .deb пакет. Всичко което съдържа тази директория ще бъде инсталирано на потребителската система когато потребителят инсталира вашия пакет, единствената разлика е че dpkg ще инсталира файловете в главната директория (`/').

Основното нещо е да накарате програмата да се инсталира в debian/tmp но да се държи правилно когато се инсталира в основната директория, тоест когато се инсталира от .deb пакет. Когато работите с програма която ползва GNU autoconf, това е лесно защото dh_make се справя автоматично с тази задача, така че който ще пакетира такава програма може да пропусне следващата секция. Но за други програми които не ползват autoconf най-вероятно ще ви се наложи да разгледате и редактирате Makefile-овете.

Ето съответната част от Makefile-а на gentoo:

# Where to put binary on 'make install'? BIN = /usr/local/bin # Where to put icons on 'make install'? Note: if you change this, # gentoo will not find the icons as it starts up. You're going to # have to alter gentoo's icon path (in the config window, "Paths" # tab) to get it work. ICONS = /usr/local/lib/gentoo/

Преди това ще трябва да добавим тези два нови реда:

# Edited for Debian GNU/Linux. DESTDIR = защото процеса на изграждане ги изисква (ще бъде обяснено по-късно в ).

След това в Makefile-а се вижда местонахождението на бинарния файл при инсталиране. Променете го на това:

# Where to put binary on 'make install'? BIN = $(DESTDIR)/usr/X11R6/bin

Но защо точно в тази директория а не в някоя друга? Защото за Debian са дефинирани няколко правила за това къде програмите трябва да бъдат инсталирани. Това е описано в Стандарт за Файлова Йерархия (виж /usr/share/doc/debian-policy/fhs/). Така че ние ще трябва да инсталираме бинарния файл в /usr/X11R6/bin вместо в /usr/local/bin, и man страницата (не съществува, но почти всяка програма има поне една, така че ще направим една по-късно) в /usr/share/man/man1 вместо в /usr/local/man/man1.

След това следва малко по-сложна ситуация. Ако промените реда на:

ICONS = $(DESTDIR)/usr/share/gentoo/ което е в съответствие с установените норми, ще трябва да редактирате и C изходния код. Но каде и какво да търсим? Може да разберете като напишете:

grep -n usr/local/lib *.[ch] (във всяка поддиректория която съдържа *.c и *.h файлове). Grep ще ви покаже името на файла и на кой ред е, когато намери съвпадение. Редактирайте тези редове и заместете usr/local/lib с usr/share - и това е всичко. Просто заместете usr/local/lib с вашият път и гледайте да не разбутате останалия код ако не разбирате от програмиране на C. :-)

След това трябва да намерите обекта install (търсете за ред започващ с `install:') и преименувайте всички указатели към директории различни от дефинираните в началото на Makefile-а. Обекта install: на gentoo изглежда така:

# ----------------------------------------- Installation # You're going to have to be root to do this! install: gentoo install ./gentoo $(BIN) install icons $(ICONS) install gentoorc-example $(HOME)/.gentoorc

След нашите промени изглежда така: # ----------------------------------------- Installation # You're going to have to be root to do this! install: gentoo-target install -d $(BIN) $(ICONS) $(DESTDIR)/etc install ./gentoo $(BIN) install -m644 icons/* $(ICONS) install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc install -d $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html

Внимателния читател ще забележи че аз промених `gentoo' на`gentoo-target' на реда `install:'. На това му се вика отстраняване на грешки :-)

Когато и да направите промени по кода които не се отнасят за Debian пакета, изпратете ги до автора на програмата за да могат да бъдат включени в следващата версия. Забележете че няма нужда да изпращате debian/* файловете но всяка друга кръпка е добре да я изпратите. И се опитайте да направите кръпката не отнасяща се само за Debian или Linux (или дори Unix!) преди да ги изпратите. Различия в библиотеките

Има и още един основен проблем: библиотеките често се различават от платформа до платформа. За пример Makefile-а може да съдържа обръщение към библиотека която не съществува в Debian или дори в Linux. В този случай нужно е да промени обръщението към някоя библиотека която съществува в Debian и изпълнява същите функции. Най-добрия начин е да коментирате тези редове защото може някой друг да се опита да компилира програмата на различна платформа, така че да има нещо което да му подскаже къде може да е проблема.

Значи, ако има в Makefile-а на вашата програма ред който изглежда горе-долу така (и програмата не иска да се компилира):

LIBS = -lcurses -lsomething -lsomethingelse

Променете го да стане така, и най-вероятно ще проработи:

LIBS = -lncurses -lsomething -lsomethingelse #LIBS = -lcurses -lsomething -lsomethingelse Задължителни файлове в debian/

Вече има нова директория в директорията на програмата (`gentoo-0.9.12'), която се казва `debian'. В нея има няколко файла. Ще ги редактираме за да можем да настроим държанието на пакета при инсталирането му. Най-важните от тях са `control', `changelog', `copyright' и 'rules', които са задължителни за всички пакети. файлът `control'

Този файл съдържа няколко стойности които dpkg и dselect ще използват за управление на пакета. Ето control файла който dh_make създава.

1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin <jrodin@jagor.srce.hr> 5 Standards-Version: 3.0.1 6 7 Package: gentoo 8 Architecture: any 9 Depends: ${shlibs:Depends} 10 Description: <insert up to 60 chars description> 11 <insert long description, indented with spaces> (Номерата на редовете са добавени от мен.)

Редове 1-5 са контролната информация на изходния пакет. Ред 1 е името на изходния пакет.

Ред 2 е секцията на дистрибуцията в която пакета ще бъде поставен. Както може би сте забелязали Debian е разделен на секции: main (свободен софтуер), non-free (не точно свободен софтуер) и contrib (свободен софтуер който зависи от не свободен софтуер). Под всяка една от тези секции съществуват подсекции които описват какъв тип са пакетите в него. За пример `admin' съдържа програми за администриране, `base' съдържа основните инструменти, `devel' - инструменти в помощ на програмиста, `doc' - документация, `libs' - библиотеки, `mail' - e-mail еклиенти и демони, `net' - мрежови приложения и демони, `x11' - специфични приложения за X11, и много други.

Нека тогава да го променим на x11.

Ред 3 описва колко важно е потребителя да инсталира този пакет. Section и priority всъщност се използват само от dselect когато сортира пакетите и те могат (и най-вероятно ще бъдат) променени от нашите FTP maintainers. Виж в Policy manual за повече информация какво да напишете в тези полета.

Тъй като това е пакет с нормален приоритет ще го оставим като optional.

Ред 4 е името и e-mail адреса на отговорника по поддръжка.

Ред 5 е версията на Debian Policy стандарта с която този пакет е съобразен (две основни версии на инсталиран debian-policy пакет).

Ако се изисква някакъв нестандартен компилатор или друг инстумент за да бъде изграден пакета, трябва да го добавите тук на `Build-Depends' реда и списък със задължителните пакети. За повече информация прочетете Packaging Manual (секция 8.7) и документацията на `build-essential' пакета.

Ред 7 е името на бинарния пакет.

Ред 8 описва аритектурата на процесора за която пакета е бил компилиран. Можем да го оставим "any" защото ще попълни съответната стойност за всяка машина за която този пакет е компилиран (виж Developer's Reference за информация относо пренасянето на пакети от една платформа на друга). Ако вяшият пакет е независим архитектурно (примерно shell скрипт, Perl скрипт или документ), променете го на "all", и прочетете по-късно относно използването на `binary-indep' правило вместо `binary-arch' за изграждането на пакета.

Ред 9 разкрива едно от най-мощните свойства на системата за пакетиране на Debian. Пакетите могат да зависят един с друг по няколко различни начина. Освен Depends:, други зависимости са Recommends:, Suggests:, Pre-Depends:, Conflicts:, Provides:, и Replaces: .

Инструментите за управление на пакети като dpkg, dselect или APT (и тяхните помощни обвивки) обикновенно се държат по един и същ начин когато работят с тези зависимости, ако ли не, то ще бъде обяснено. (виж , , , , )

Ето какво обикновенно означават:

Depends:

Този пакет нямя да бъде инсталиран докато пакетите от които зависи не бъдат инсталирани. Ползвайте го ако вашата програма няма изобщо да тръгне (или ще нанесе щети) докато не присъства даден пакет. Recommends:

Dselect няма да инсталира вашият пакет докато пакетите които препоръчва не са инсталирани. Dpkg и APT обаче ще ви позволят да го инсталирате. Ползвайте го за пакети които не са абсолютно задължителни но обикновенно се използват с вашата програма. Suggests:

Когато потребителя инсталира вашата програма, dselect ще предложи да бъдат инсталирани и други пакети. Dpkg и APT не се съобразяват с това. Използвайте го за пакети които ще работят добре с вашата програма но като цяло не са необходими. Pre-Depends:

Това е по силно и от Depends:. Пакета няма да бъде инсталиран докато пакетите от които той зависи не бъда инсталирани и правилно конфигурирани . Ползвайте го много внимателно и то след като сте го обсъдили в debian-devel mailing list. С две думи, не го ползвайте :-) Conflicts:

Този пакет няма да бъде инсталиран докато всички пакети с които той е в конфликт не бъдат премахнати. Използвайте го ако вашата програма 100% няма да тръгне (или ще нанесе щети) ако е инсталирана определена програма. Provides:

За някои видове пакети са дефинирани множество алтернативни виртуални имена. Можете да намерите пълния списък в файла /usr/share/doc/debian-policy/virtual-package-names-list.text.gz. Използваите го ако вашата програма осигурява функция на съществуващ виртуален пакет. Replaces:

Използвайте го когато вашата програма замества файлове от друг пакет или напълно замества даден пакет (използва се заедно с Conflicts:). Файловете от именувания пакет ще бъдат премахнати преди да бъде инсталиран вашият пакет.

Всички тези полета имат еднакъв синтаксис. Те са списък от пакети разделени със запетая. Тези имена на пакети също може да бъдат алтернативни пакети разделени с вертикална черта | (pipe symbols). Полетата могат да ограничат тяхната приложимост за определени версии за всеки именуван пакет. Версиите са изброени в скоби след всеки индивидуален пакет и трябва да включват зависимости последвани от номер на версия. Зависимостите могат да бъдат: <<, <=, =, >= и >> за съответно по-стара версия, по-стара или равна, точно тази, по-нова или равна и по-нова версия.

И накрая последното нещо с което трябва да се запознаете е $(shlibs:Depends). Това е генерирано автоматично от и попълнено от с имената на всички споделени библиотеки които вашата програма използва, такива като libc6 или xlib6g, такак че не се налага да ги указвате ръчно. И казано с две думи - ред 9 го оставяме както си е :-)

Ред 10 съдържа списък с предложени пакети за инсталация. В този случай това е само `file' защото gentoo може да ползва някои свойства предоставени от този програма/пакет.

Ред 11 е кратко описание. Повечето потребители иползват 80 колонен екран така че не трябва да е по дълго от 60 символа. Аз ще го променя на "A fully GUI configurable GTK+ file manager".

Ред 12 е за пълното описание. Тук трябва да има детайлно описание на пакета. 1-вата колона на всеки ред трябва да е празна, тоест да оставяте по един интервал. Не трябва да има празни редове, но може да ползвате . (точка) за да симулирате празен ред. Също така не трябва да има повече от един празен ред след края на пълното описание.

Ето и редактирания control файл:

1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <jrodin@jagor.srce.hr> 5 Standards-Version: 3.0.1 6 7 Package: gentoo 8 Architecture: any 9 Depends: ${shlibs:Depends} 10 Suggests: file 11 Description: A fully GUI configurable GTK+ file manager 12 gentoo is a file manager for Linux written from scratch in pure C. It 13 uses the GTK+ toolkit for all of its interface needs. gentoo provides 14 100% GUI configurability; no need to edit config files by hand and re- 15 start the program. gentoo supports identifying the type of various 16 files (using extension, regular expressions, or the 'file' command), 17 and can display files of different types with different colors and icons. 18 . 19 gentoo borrows some of its look and feel from the classic Amiga file 20 manager "Directory OPUS" (written by Jonathan Potter). (номерата на редовете са добавени от мен.) файлът `copyright'

Този файл съдържа информация относно от къде е изтеглен пакета , copyright и информация за лиценза. Неговия формат не е продиктуван от Policy, но съдържанието му е (секция 6.5). Dh_make го създава по подразбиране и ето как изглежда:

1 This package was debianized by Josip Rodin <jrodin@jagor.srce.hr> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from <fill in ftp site> 5 6 Upstream Author(s): <put author(s) name and email here> 7 8 Copyright: 9 10 <Must follow here> (номерата на редовете са добавени от мен.)

Важните неща които трябва да присъстват в този файл са мястото от където е взета тази програма, точния лиценз и copyright. Трябва да включите пълния лиценз освен ако той не е някой от основните свободни лицензи като GNU GPL или LGPL, BSD или the Artistic license, за тях просто може да посочите съответния файл в директорията /usr/share/common-licenses/ която съществува във всяка Debian система. Gentoo е лицензиран под GNU General Public License така че ще променим файла така:

1 This package was debianized by Josip Rodin <jrodin@jagor.srce.hr> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from: ftp://ftp.obsession.se/gentoo/ 5 6 Upstream author: Emil Brink <emil@obsession.se> 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License. 13 On Debian systems, the complete text of the GNU General Public 14 License can be found in /usr/share/common-licenses/GPL file. (номерата на редовете са добавени от мен.) файлът `changelog'

Този файл задължително трябва да съществува, той има специален формат описан в Packaging Manual (секция 3.2.3). Форматът се използва от dpkg и от други програми за да получат номер на версията, преработка, дистрибуция и приоритет (спешност) на вашия пакет.

За вас също ще е полезен тъй като е добре да имате документирани всичките промени които сте направили. Също така ще помогне на тези които са изтеглили вашия пакет да разберат дали има неразрешени проблеми с този пакет за които трябва да се разбере веднага. Той ще бъде съхранен като `/usr/share/doc/gentoo/changelog.Debian.gz' в бинарния пакет.

Dh_make създава по подразбиране ето такъв файл:

1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 5 -- Josip Rodin <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 21:02:14 +0100 6 7 Local variables: 8 mode: debian-changelog 9 End: (номерата на редовете са добавени от мен.)

Ред 1 е името на пакета, версията, дистрибуцията и приоритета. Името трябва да съвпада с името на пакета с изходния код., дистрибуцията трябва да е или `unstable' или `experimental' (засега) и приоритета трябва да е променен на нещо по голямо от `low'. :-)

Редове 3-5 са log записи където са отразени промените направени в тази версия на пакета (не промените по изходния код които са правени от авторите - има специален файл за тази цел, който е създаден от авторите на програмата, инсталира се в /usr/share/doc/gentoo/changelog.gz). Новите редове трябва да бъдат вмъквани в началото на файла точно над първия ред започващ със звездичка (`*'). Можете да направите това с помоща на , (редове 7-9 съдържат информация относно редактора Emacs), или който и да е друг редактор. Трябва да се получи нещо такова:

1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 21:02:14 +0100 8 9 Local variables: 10 mode: debian-changelog 11 End: (номерата на редовете са добавени от мен.)

Когато публикувате нова версия, трябва да увеличите номера на версията. Най-лесно ще го направите с `dch -i` или `dch -v <version>-<revision>` и после добавете коментари чрез любимия ви редактор. Полезен съвет: как най-лесно мога да получа датата в изисквания формат? Ползвайте `822-date`, или `date -R`.

Информацията за новата версия е добавена в началото на changelog файла. Ето как изглежда той след промените:

1 gentoo (0.9.12-2) unstable; urgency=low 2 3 * Fixed a glitch in the menu file. 4 5 -- Josip Rodin <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 22:15:39 +0100 6 7 gentoo (0.9.12-1) unstable; urgency=low 8 9 * Initial Release. 10 * This is my first Debian package. 11 * Adjusted the Makefile to fix $DESTDIR problems. 12 13 -- Josip Rodin <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 21:02:14 +0100 14 15 Local variables: 16 mode: debian-changelog 17 End: (номерата на редовете са добавени от мен.)

Може да прочетете повече относно нови версии/прегледи на пакетите в . файлът `rules'

Сега трябва да погледнем и правилата които ще използва за да създаде пакета. Този файл всъщност е един вид Makefile, тъй като се се изпълнява чрез `make -f`, но е различен от този който идва с изходния код.

Всеки файл `rules', както и всеки Makefile се състои от няколко правила които указват как да бъде манипулиран изходния код. Всяко правило се състои от цел, имена на файлове или имена на действия които трябва да бъдат изпълнени. Правилата които искате да бъдат изпълнени се извикват като аргументи на командния ред (примерно: `./debian/rules build` или `make -f rules install`). След името може да укажете зависимост, програма или файл от който зависят правилата. След това може да укажете брой команди (разделени с <tab>!) докато се достигне празен ред. След него започва ново правило. Множество празни редове и редове започващи с `#' (диез) се третират като коментари и съответно се игнорират.

Хмм, най-вероятно вече достатъчно се объркахте но ще ви стане ясно след като изследваме файла `rules' който dh_make създава по подразбиране. Препоръчвам ви да прочетете информацията относно `make' (info make) за повече подробности.

Важно е да знаете че файла `rules' който е създаден dh_make е просто за да ви подскаже как би трябвало да изглежда този файл. На по простите пакети най-вероятно ще работи но за по-сложните пакети не се страхувайте а го редактирате така че да пасне на нуждите на програмата. Не променяйте единствено имената на правилата защото всички инструменти използват тези имена както е указано в Packaging Manual.

1 #!/usr/bin/make -f 2 # Made with the aid of dh_make, by Craig Small 3 # Sample debian/rules that uses debhelper. GNU copyright 1997 by Joey Hess. 4 # Some lines taken from debmake, by Christoph Lameter. 5 6 # Uncomment this to turn on verbose mode. 7 #export DH_VERBOSE=1 8 9 # This is the debhelper compatability version to use. 10 export DH_COMPAT=1 11 12 build: build-stamp 13 build-stamp: 14 dh_testdir 15 16 # Add here commands to compile the package. 17 $(MAKE) 18 19 touch build-stamp 20 21 clean: 22 dh_testdir 23 dh_testroot 24 rm -f build-stamp 25 26 # Add here commands to clean up after the build process. 27 -$(MAKE) clean 28 29 dh_clean 30 31 install: build-stamp 32 dh_testdir 33 dh_testroot 34 dh_clean -k 35 dh_installdirs 36 37 # Add here commands to install the package into debian/tmp. 38 $(MAKE) install DESTDIR=`pwd`/debian/tmp 39 40 # Build architecture-independent files here. 41 binary-indep: build install 42 # We have nothing to do by default. 43 44 # Build architecture-dependent files here. 45 binary-arch: build install 46 # dh_testversion 47 dh_testdir 48 dh_testroot 49 # dh_installdebconf 50 dh_installdocs 51 dh_installexamples 52 dh_installmenu 53 # dh_installemacsen 54 # dh_installpam 55 # dh_installinit 56 dh_installcron 57 dh_installmanpages 58 dh_installinfo 59 # dh_undocumented 60 dh_installchangelogs 61 dh_link 62 dh_strip 63 dh_compress 64 dh_fixperms 65 # You may want to make some executables suid here. 66 dh_suidregister 67 # dh_makeshlibs 68 dh_installdeb 69 # dh_perl 70 dh_shlibdeps 71 dh_gencontrol 72 dh_md5sums 73 dh_builddeb 74 75 binary: binary-indep binary-arch 76 .PHONY: build clean binary-indep binary-arch binary install (номерата на редовете са добавени от мен.)

Най-вероятно сте срещали редове като 1-ви от shell и Perl скриптовете. Той указва на операционната система че този файл трябва да бъде обработен от /usr/bin/make.

Редовете от 12 до 19 описват правилото `build' (и неговото под-правило `build-stamp') който стартира Makefile-а за да се компилира програмата.

Правилото `clean' както е описано на редове 21-29 изчиства всички ненужни бинарни файлове и автоматично създадени неща който са останали от процеса на изграждане. Правилата трябва да работят винаги (дори когато и изходния код Инсталационния процес започва при правилото `install' на 31 ред. То всъщтност стартира правилото `install' от Makefile-а но инсталацията се прави в директория `pwd`/debian/tmp - ето защо указахме $(DESTDIR) като основна директория за инсталиране в Makefile-а на gentoo.

Както ни подсказва и коментара, правилото `binary-indep на ред 41 се използва когато изграждаме архитектурно независими пакети. Тъй като няма да правим това не се налага да пипаме нищо. Ако пакета е от типа `Architecture: all', трябва да преместим всичките команди под това правило а правилото `binary-arch' да оставим празно.

В следващото правило - `binary-arch', на редове от 45 до 73 стартираме няколко малки програмки от пакета debhelper които помагат пакета да бъде съобразен с Policy.

Имената им започват с dh_ и останалото е описание за какво служи програмката. Имената им говорят сами по себе си но ето малко допълнителна информация: проверява дали сте в правилната директория (тоест в основната директория на изходния код на програмата), проверява дали имате root права които са нужни за binary* целите и clean, копира всички man страници които намери в дървото с изходния код (внимавайте това е DWIM), премахва дебъг символите от изпълнимите файлове и библиотеките за да станат по-малки, компресира man страниците и документацията по-големи от 4 kB, копира файловете които се отнасят към пакета (скриптовете) в директория debian/tmp/DEBIAN, изчислява зависимостите между споделените библиотеки и изпълнимите файлове и библиотеки, добавя необходимите неща и инсталира файла control, генерира MD5 checksums за всички файлове в пакета.

За повече изчерпателна информация какво точно вършат всичките тези dh_* скриптове и какви са техните опции, прочетете страниците с ръководство. Съществуват и други доста полезни dh_* скриптове които не са споменати тук. Ако се нуждаете от тях прочетете документацията на debhelper.

В секцията binary-arch трябва да коментирате всички редове които не са ви нужни. За gentoo ще коментирам редовете относно testversion, emacsen, pam, init, cron, manpages, info, undocumented, suidregister, makeshlibs, и perl, просто защото gentoo не се нуждае от тях. А на ред 60 трябва да добавя `FIXES' защото така е именуван оригиналния changelog файл.

Последните два реда (заедно с всички други редове които не са обяснени) са просто повече или по-малко нужни неща за които може да прочетете в ръководството на make и в Packaging Manual. Но засега те не са важни. Други файлове в debian/

Съществуват още няколко файла в поддиректорията debian/ като повечето от тях са с разширение `.ex' което означава че те са примерни. Ако желаете или се налага да използвате някой от тяхните свойства, разгледайте ги и прочетете съответната документация (Policy Manual), преименувайте ги като премахнете `.ex' разширението и ако е нужно ги редактирайте заедно с файла rules. Често използваните от тях са обяснени в следващите секции. README.Debian

Всякакви допълнителни детайли или несъответствие между оригиналния пакет и вашата дебианизирана версия трябва да бъдат описани тук. Dh_make създава примерен файл който изглежда така: gentoo for Debian ---------------------- <possible notes regarding this package - if none, delete this file> Josip Rodin <jrodin@jagor.srce.hr>, Wed, 11 Nov 1998 21:02:14 +0100

Тъй като няма какво да опишем в този файл - можем спокойно да го изтрием. conffiles

Едно от най-дразнещите неща при софтуера е, когато загубите много време и усилия, за да настроите една програма, и когато я обновите да изгубите всички промени, които сте направили по конфигурационния файл.Debian разрешава този проблем като маркира конфигурационните файлове така че когато обновявате пакета да бъдете попитан дали искате да запазите старата конфигурация или не. Това се прави като се добавя пълният път до всеки конфигурационен файл (те обикновенно са в /etc) по един на ред в файла conffiles.

Gentoo има един конфигурационен файл, /etc/gentoorc, и ние ще го добавим в файла `conffiles'. Не е нужно да имате този файл ако вашата програма няма конфигурационен файл. dirs

Този файл указва директориите в които ще се инсталира програмата в случай че при нормалната инсталация (make install) не са създадени. По подразбиране файла изглежда така:

usr/bin usr/sbin

Забележете че директориите не започват с `/'. Нормално е да ги променим на:

usr/X11R6/bin usr/X11R6/man/man1 но тъй като тези директории са създадени в Makefile-а този файл не ни е нужен и можем да го изтрием. manpage.1.ex

Файловете завършващи с *.ex са примери за това как да добавим някакъв вид поддръжка в този пакет. За да използвате някой от тях премахнете .ex разширението и го редактирайте. Ако не искате да го използвате просто го изтриите.

Програмата ви трябва да има man страница. Ако няма, това е скелета върху който можете да направите една. Вижте man страницата относно за кратко описание как да създадете man страница. Уверете се че сте преименували този файл на името на програмата и разширението да съответства на тази в която искате да бъде поставена man страницата. Ето кратко описание на секциите:

Секция | Описание | Бележки 1 Потребителски команди Изпълними команди или скриптове 2 Системни извиквания Функции на kernel-а 3 Библиотечни извиквания Функции на системните библиотеки 4 Специални файлове Обикновенно се намират в /dev 5 Файлови формати Примерно формата на /etc/passwd 6 Игри Или други несериозни неща 7 Макро пакети Такива като man макроси 8 Системна Администрация Обикновенно програми стартирани само от root. 9 Kernel routines Системни извиквания и вътрешни особенности

Съответно man страницата на gentoo трябва да се казва gentoo.1 или gentoo.1x защото това е X11 програма. В оригиналния пакет няма gentoo.1 страница затова аз направих една като ползвах примерната страница и документацията от изходния код. menu.ex

Потребителите на X Window System обикновенно имат window manager с меню което може да бъде настроено да стартира програми. Ако те са инсталирали Debian пакета "menu", за всяка програма ще бъдат създадени комплект менюта. Това не е задължително изискване от Debian Policy но потребителите ще го оценят. Можем да добавим Gentoo в менютата като редактирамето този файл. Ето примерния файл който създава dh_make:

?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\ title="gentoo" command="/usr/bin/gentoo"

Първото поле указва какъв вид интерфейс изисква програмата (тоест текстов или X11). Следва менюто и подменюто в което програмата трябва да се добави. Може да прочетете за списък със секциите в: /usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1. Третото поле е името на програмата. Четвъртото е иконата на програмата или none ако няма такава. Петото поле е текста който ще се появи в менюто. И накрая в шестото поле се намира командата с която ще бъде стартирана програмата.

И така, променяме горните редове на:

?package(gentoo):needs=X11 section=Apps/Misc \ title="Gentoo" command="/usr/X11R6/bin/gentoo"

За повече информация виж , и /usr/share/doc/debian-policy/menu-policy.html/. watch.ex

Може да го ползвате като допълнение към програмите и (в devscripts пакета) за наблюдение на адреса откъдето сте взели оригиналния изходен код. Ето какво сам сложил аз:

# watch control file for uscan # Site Directory Pattern Version Script ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate

Съвет: свържете се с интернет и стартирайте "uscan" в директорията на програмата след като сте създали файла. И прочетете man страниците. ex.doc-base

Ако вашият пакет има HTML или някакъв друг вид документация (освен man или info страници) трябва да използвате `doc-base' файла за да ги регистрирате така че да могат да бъдат намерени от или .

Ето как изглежда doc-base файла на gentoo:

Document: gentoo Title: Gentoo Manual Author: Emil Brink Abstract: This manual describes what Gentoo is, and how it can be used. Section: Apps/Tools Format: HTML Index: /usr/share/doc/gentoo/html/index.html Files: /usr/share/doc/gentoo/html/*.html

За повече информация относно файловия формат, виж и doc-base ръководството в /usr/doc/doc-base/doc-base.html/index.html. postinst.ex, preinst.ex, postrm.ex, prerm.ex

Тези файлове се наричат скриптове на отговорника по поддръжка, скриптове които се поставят в контролната област на пакета и се стартират от dpkg когато инсталирате, обновявате или премахвате пакета.

За сега трябва да избягвате каквито и да било редакции на ръка върху тези скриптове защото са доста сложни. За повече информация погледнете в Packaging Manual, секция 6 и разгледайте примерния файл направен от dh_make.

Вече сме готови да изградим пакета. Заключителни стъпки Изграждане на пакета

Влезте в основната директория на програмата и изпълнете тази команда:

dpkg-buildpackage -rfakeroot

Това ще свъши всичката работа като трябва да въведете два пъти вашият PGP секретен ключ. След като всичко приключи ще намерите четири нови файла в предишната директория (~/debian/):

gentoo_0.9.12-1_i386.deb

Това е пълният бинарен пакет. Може да използвате dpkg или dselect за да го инсталирате или премахнете както всеки друг пакет gentoo_0.9.12.orig.tar.gz

Това е оригиналният изходен код на програмата, така че ако някой иска да изгради наново вашия пакет да има с какво да работи. Или пък ако не използват пакетиращата система на Debian но имат нужда да изтеглят изходния код и да го компилират. gentoo_0.9.12-1.dsc

Това е кратко резюме на съдържанието на изходния код. Файлът е генериран от файла gentoo-0.9.12/debian/control и се използва от когато се разпакетира изходния код. Този файл е подписан с PGP така че хората да са сигурни че файла е наистина ваш. gentoo_0.9.12-1.diff.gz

Този компресиран файл съдържа всички промени и добавки които сте направили към оригиналния код във формат известен като "унифициран diff". Файлът е създаден и се използва от . gentoo_0.9.12-1_i386.changes

Този файл описва всички промени в текущата версия на пакета и се използва от програмите по поддръжка на Debian FTP архива за да инсталират бинарните и пакетите с изходния код в него. Той е генериран от части от gentoo-0.9.12/debian/changelog и от .dsc файла.

С течение на времето, докато работите с пакета нови възможности ще бъдат добавяни. Хората които изтеглят вашия пакет могат бързо да проверят в този файл какви са били промените. Дългите низове от числа са MD5 checksum-и за споменатите файлове. Лицето което свали вашите файлове може да ги тества с и ако номерата не съвпадат ще разбере че или файла е повреден или е бил хакнат. Този файл е и подписан с PGP за да може хората да са още по сигурни че е наистина ваш.

Когато работите с голям пакет може да искате да не изграждате наново целия пакет всеки път когато направите някоя малка промяна в debian/rules. С цел тестване можете да направите .deb файл без да изграждате наново целия изходен код ето така:

fakeroot debian/rules binary

Само се уверете че правилото `install' Проверяване на пакета за грешки

Стартирайте въху вашия .changes файл; тази програма ще провери за много основни проблеми при пакетиране. Командата е:

lintian -i gentoo_0.9.12-1_i386.changes

Разбира се заместете името на файла с този генериран за вашата програма. Ако се появят грешки (редовете започващи с Е:) прочетете разясненията (редовете започващи с N:), поправете грешките и го изградете наново както е описано в . Има редове които започват с W: които са само предупреждения така че можете да бъдете сигурен че пакета е добре (но най-вероятно изисква леки настройки).

Можете да изградите пакета с dpkg-buildpackage и да стартирате lintian само с една команда и тя е .

Погледнете вътре в пакета като използвате файлов мениджър като , или го разпакетирате в някоя временна директория като използвате . Огледаите за ненужни файлове в бинарния и пакета с изходния код в случай че нещо се е объркало и са останали непочистени файлове. Съвет: `zgrep ^+++ ../gentoo_0.9.12-1.diff.gz` ще ви покаже списък с промените/добавките към изходния код, а `dpkg-deb -c gentoo_0.9.12-1_i386.deb` ще покаже списък с файловете от пакета.

Инсталирайте пакета за да го тествате, тоест използвайте командата като root. Пробвайте да я инсталирате на машини различни от вашата и наблюдавайте внимателно за всякакви предупреждения или грешки при инсталацията и при работата на праграмата.

В послесдствие когато изграждате нова версия трябва да направите следното за да се уверите че обновяването на пакета работи: обновете от предишна версия (и от версията на последния публикуван Debian), върнете старата версия, инсталирайте пакета като нов пакет (без инсталирана предишна версия), деинсталирайте и я инсталирайте отново и после я почистете. "Качване" на пакета

След като напълно сте тествали вашия пакет, ще трябва да "качите" файловете на master.debian.org, като използвате . Първо трябва да настроите конфигурационния файл на dupload - ~/.dupload.conf . Поставете нещо такова в него:

package config; $default_host = "master"; $cfg{"master"}{"method"} = "scpb"; $cfg{"master"}{"login"} = "joy"; $cfg{"master"}{"visibleuser"} = "jrodin"; $cfg{"master"}{"visiblename"} = "jagor.srce.hr"; $cfg{"master"}{"fullname"} = "Josip Rodin"; $cfg{"non-us"}{"method"} = "scpb"; $cfg{"non-us"}{"login"} = "joy"; $cfg{"non-us"}{"visibleuser"} = "jrodin"; $cfg{"non-us"}{"visiblename"} = "jagor.srce.hr"; $cfg{"non-us"}{"fullname"} = "Josip Rodin"; 1;

Разбира се сменете моите персонални настройки с вашите и прочетете man-страницата за да разберете какво означава всяка от тези опции.

После се свържете към интернет и изпълнете тази команда:

dupload --to master gentoo_0.9.12-1_i386.changes

Dupload проверява дали md5 сумите на файловете съвпадат с тези от .changes файла така че ако се разминават че ви предупреди за изградите наново пакета както е описано в за да може да бъде правилно "качен" пакета.

Dupload ще ви поиска паролата за master.debian.org, ще "качи" пакетите и ще анонсира кратко описание на пакета в Ако живеете в Европа може да ползвате други сървъри вместо master. За повече детайли погледнете в , и в Developer's Reference. Обновяване на пакета

Да предположим че е попълнен бъг рапорт за вашия пакет, #54321, и в него е описан проблем с който може да се справите. За да създадете нова Debian преработка на пакета се нуждаете от: Поправете грешката в изходния код на пакета разбира се. Добавете нова преработка в Debian changelog файла чрез `dch -i` и добавете кратко описание на бъга и решението последвано от "Closes: #54321". По този начин рапорта автоматично ще бъде закрит от автоматичния софтуер за поддръжка на архива когато вашия пакет бъде приет в Debian архива. Повторете , , и . Разликата е че този път оригиналния изходен код няма да бъде включен тъй като той не е променян и присъства в архива на Debian.

Нека разгледаме малко по сложна ситуация - нова версия на оригиналния изходен код е публикувана и разбира се вие искате да я пакетирате. Нужно е да направите следното: Изтеглете новия изходен код и поставете архива (именуван `gentoo-0.9.13.tar.gz') в директория преди стария изходен код (тоест ~/debian/). Влезте в старата директория с изходния код и стартирайте това: uupdate -u gentoo-0.9.13.tar.gz Разбира се заменете името на файла с това на вашата програма. правилно ще преименува архива, ще се опита да приложи всички промени от предишния ви .diff.gz файл, и ще обнови новия debian/changelog файл. Сменете директорията на `../gentoo-0.9.13', и повторете вече познатите ви стъпки , , и .

Ако сте конфигурирали `debian/watch' файла както е описано в може да стартирате което автоматично ще провери за нови версии, ще ги изтегли и ще стартира uupdate. Къде да потърсим помощ

Преди да решите да зададете вашият въпрос на някое публично място просто RTFM. Това включва /usr/share/doc/dpkg, /usr/share/doc/debian, /usr/share/doc/package/* файловете и man/info страниците за всички програми споменати в този документ. Когато получите бъг рапорт (да, истински бъг рапорт!) ще разберете че е време да поровите в и да прочетете документацията за да можете ефикасно да се справите с рапортите.

С присъединяването си към Ако все още имате въпроси, питайте на Разработчици на Debian mailing list на Дори ако всичко работи добре, време е да започнете да се молите. Защо? Защото след няколко часа (или дни) потребители от цял свят ще започнат да използват вашия пакет, и ако сте направили някоя критична грешка пощата ви ще бъде бомбандирана от голям брой гневни Debian потребители ... Шегичка :-)

Отпуснете се и бъдете готов за бъг рапорти, защото има още много работа докато бъде в крак с Debian политиката (още веднъж, за повече детайли прочетете истинската документация). Успех!