Убунтариум

индекс
253,47

Стать мэинтейнером. Часть первая

Когда я прочитал эту и эту статьи, мне захотелось рассказать, как человек может внести свой маленький вклад в распространение своей любимой программы среди пользователей всеми любимой операционной системы. Полистав Убунтариум, я увидел, что статей на эту тему вроде бы не было, поэтому я решил смело приняться за дело.
(Части 2, 3 и 4)

Введение


Сразу вынужден оговориться: моей основной и любимой системой является в первую очередь Debian, а не Ubuntu, в сборке пакетов у них бывает некоторая разница, о ней я буду рассказывать отдельно.
И ещё: если вы заинтересуетесь включением собранных вами пакетов именно в Debian, то лучше написать об этом в комментариях и вступать в соответствующий блог. Он выглядит мертвым, но такой рассказ лучше было бы размещать именно там, поэтому если вам будет интересно, об этом я напишу тоже там :)

Какой софт подойдёт?


Когда вы хотите собрать какую-то программу, в первую очередь стоит задуматься, а возьмут ли её в дистрибутив? Дело в том, что вся идеология дистрибутива Debian в первую очередь регулируется таким интересным документом, как Социальный контракт (или Общественный Договор) Debian. В основном этот контракт гласит, что:
  • Debian останется Свободным ПО на все 100%
  • Наши разработки будут возвращаться Сообществу Свободного ПО
  • Мы не будем скрывать проблемы
  • Главное для нас — это наши пользователи и Свободное ПО
  • Разработки, которые не отвечают нашим стандартам Свободного ПО, могут распространяться с Debian, но не являются его частью

Если более подробно: вся система Debian была, есть и будет воистину свободной системой. В ней никогда не будет несвободных компонентов. Все наработки, сделанные в рамках Debian, будут лицензированы как свободное ПО и возвращены сообществу. Все исправления и патчи к программам, сделанные в рамках Debian, будут предложены авторам программ (совершенно бесплатно :) ). Все ошибки и проблемы в дистрибутиве так же свободны и открыты с момента сообщения о них (об этом позже). Для несвободного программного обеспечения в Debian предусмотрена специальная секция non-free. Пакеты, которые туда помещаются, не являются частью Debian, хотя и распространяются вместе с ним.
«А как у нас?» — спросят пользователи Убунту. Ровно так же. В Убунту есть «Обещание Убунту» (лежит на главной странице ubuntu.com) и документ Философия Убунту. В целом, ограничения практически те же самые, в Убунту они чуть мягче, но рекомендую ориентироваться на Debian.
Итак, если мы решили, что наша идеология совпадает с идеологией Debian/Ubuntu, то можно приниматься за следующий пункт.

В какую секцию дистрибутива включить наш будущий пакет?


Дистрибутивы Debian и Ubuntu разбиты на несколько категорий, у каждого свои. Подключая и отключая у себя в настройках apt какие-то из этих категорий, мы можем как полностью оградить себя от несвободного программного обеспечения, так и обставить себя им со всех сторон. Какие же категории где бывают?
В Debian их 3 основных (память мне говорит, что когда-то была еще секция non-US, но сейчас её вроде бы уже не осталось):
  1. main — ПО в этой категории является абсолютно свободным или, как говорят красноглазые фанаты, Ъ-вым. Чтобы попасть в эту категорию, ваш пакет должен быть сам свободным, не требовать для сборки (в Build-Depends) и не предлагать для установки (в Depends, Recommends и Suggests) никаких пакетов не из main и быть не настолько глючным, чтобы разработчики Debian отказались его поддерживать
  2. contrib — пакеты в этой категории также обязаны быть абсолютно свободными и не слишком глючными, но они имеют право каким-либо образом зависеть от пакетов в contrib, non-free и даже требовать для сборки те пакеты, которых вообще нет в Debian.
  3. non-free — в эту категорию, как ни странно, тоже отбор есть. ПО, претендующее на попадание в non-free, должно быть не слишком глючным (это стандартное требование, как вы успели заметить) и не иметь лицензионных ограничений, которые явно не позволят поместить его даже туда.

Помимо этого все пакеты должно соответствовать суровому документу Политика Debian, но о нём в следующих выпусках.
В Убунту категории целых четыре и деление немножко иное. Всё ПО условно делится на две группы: поддерживаемое и неподдерживаемое. Пакеты из первой группы официально поддерживаются разработчиками Ubuntu (или, как они себя называют, MOTU — Masters(Maintainers) of the Universe), второе собирается посторонними мэинтейнерами. В каждой группе есть категория для свободного и для несвободного программного обеспечения. Таким образом мы получаем 4 категории:
  1. main — поддерживаемое свободное ПО
  2. restricted — поддерживаемое несвободное ПО (в такую интересную категорию попадают некоторые несвободные драйверы и подобные жизненно важные для нормальной работы дистрибутива вещи)
  3. universe — неподдерживаемое свободное ПО
  4. multiverse — неподдерживаемое несвободное ПО

В основном критерии распределения всё те же, что и в Debian, за одним исключением: в main разрешены некоторые несвободные шрифты и firmware, если они распространяются бесплатно и жизненно необходимы для нормального функционирования системы. Также, в Убунту есть еще одна тайная категория commercial — в которую помещаются пакеты, имеющие ограничения на распространение, но для которых Canonical таки получил соответствующее разрешение у правообладателей. Раньше туда входили RealPlayer и Opera, но в следующих после Feisty Fawn дистрибутивах от этой категории вроде бы отказались.

А какое же ПО считать свободным?


В этом вопросе и Debian, и Ubuntu руководствуются одним документом (который, кстати, был принят и всем сообществом свободного ПО за основу определения OpenSource). Это так называемые «Критерии Debian по определению Свободного ПО» (Debian Free Software Guidelines или DFSG), которые являются частью вышеупомянутого Социального контракта Debian. Перечислять и расписывать их все не имеет смысла, поскольку их по вышеупомянутой ссылке можно почитать на русском языке, поэтому расскажу коротко:
  1. Чтобы ПО считалось свободным, оно не должно ограничивать своё распространение или продажу и требовать каких-то отчислений и гонораров
  2. ПО обязано распространять исходные тексты и разрешать их совместное и раздельное распространение с бинарными пакетами
  3. ПО обязано разрешать создавать производные работы и распространять их по той же лицензии, что и оно само. ПО может запрещать изменения исходного кода только в случае, если разрешено создание и совместное с ПО распространение патчей, накладываемых на него при сборке бинарных пакетов.
  4. ПО не должно создавать какой-либо дискриминации людей, в том числе по области деятельности — каждый имеет право применять его где хочет.
  5. Лицензия не должна применяться только к Debian или Ubuntu, она едина для всех.
  6. Лицензия не должна каким-либо образом ограничивать другое ПО.

Таким образом, в Debian существует список основных лицензий, распространяемое под которыми ПО можно считать свободным: GPL, LGPL, Modified BSD License, Perl Artistic License, Apache License, CC BY-SA 3.0 и ряд других. Вместе с тем, некоторые распространенные лицензий в силу тех или иных причин считаются несовместимыми с Debian — это GNU FDL, практически все Creative Commons лицензии (кроме упомянутой BY-SA 3.0) и другие. С полным списком рассмотренных Debian лицензий можно ознакомиться здесь. Вместе с тем всегда нужно помнить, что разработчики Debian каждый раз выносят решение по конкретной программе, а не по абстрактной лицензии.

Где посмотреть на имеющиеся пакеты и их баги? Социальный контракт обещал, что любой может это сделать!


Debian свято блюдёт свой контракт. Любая, даже только запланированная к «пакетированию» программа (про которую какой-то мэинтейнер разместил сообщение, что планирует её упаковать) мгновенно попадает в систему отслеживания ошибок. Любой пользователь может зайти туда и просмотреть информацию о интересующем его пакете. Для пакетов, только предполагающихся к публикации (а также требующих доработки, ищущих нового мэинтейнера и т.п.) существует специальный мета-пакет WNPP. Например, зайдя сюда, мы найдём информацию о предполагающейся к пакетированию программе qutIM и переписку нескольких мэинтейнеров по этому поводу.
В Убунту есть аналогичная система — Launchpad. Здесь, например, можно посмотреть, как выглядит страница пакета qutIM на Launchpad.

Итог


Мы получили представление о том, как распределяется ПО в Debian и Ubuntu, где его там искать и какие бывают лицензии. В следующий раз, если статья окажется кому-то интересной, я расскажу, кто же строже — Debian или Ubuntu, какие программы пригодятся вам для создания пакетов, почему вот этот подход в Убунту является в корне неверным, из-за чего столь многократно упоминаемый мною qutIM так до сих пор и не попал в Debian, и какие еще подводные камни ожидают желающего собрать пакет для любимого дистрибутива.
+49
29 января 2009, 02:19
35

комментарии (26)

+2
FRAGIL3 #
Очень интересная статья, надеюсь количество мэинтейнеров будет расти))
Только вот про подход в Убунте, в последнем абзаце я как-то не очень понял)) Вы на сборку из исходников намекаете что-ли?)
+1
Scioner #
Скорее всего именно на сборку. Пакетные дистрибутивы должны быть пакетными :)
+1
FRAGIL3 #
Это верно, однако в Ubuntu зачастую ситуация такова, что приходится искать или готовые deb-пакеты, либо собирать руками, так как свежих версий софта в официальном репозитории не дождёшься.
Хотя как вариант можно подключать репозитории с лаунчпада.
+1
Scioner #
Вариантов, действительно, много. Ланчпад, нагуглить собранный deb-пакет, накрайняк — примитивно собрать пакет самому, каким-нибудь checkinstall'ом.
Это несложно, правда. И дистр остаётся пакетным.
+1
FRAGIL3 #
Про checkinstall не подумал, да)
+1
Deepwalker #
Дело ведь не только в том, чтобы оставить дистр пакетным — из пакетов можно сделать локальный репозиторий. К примеру у нас был свой, в нем лежал пропатченый rdesktop и еще пара программ — а так как машин в сети было много, это сильно облегчало жизнь.

Причем как сделали патченый rdesktop — просто переправили стандартные скрипты сборки этого пакета от Ubuntu. Вот pidgin я думаю тем же методом было бы достаточно просто обточить напильником.
+1
Deepwalker #
Лучшим решением является сборка пакета. Еще лучше собирать его правильно — через специальные средства дистрибутива. make install вообще запретная комбинация, только для продвинутых, которые понимают что и куда поставится, и как это потом вычистить, а также влияние устанавливаемых файлов на систему — часты глюки от установленных вручную библиотек, к примеру.

Ну и главное — освоив сборку пакетов можно стать сопровождающим: )
0
Frosty #
А я применяю такой вариант: сначала ставлю интересующий пакет, а затем накатываю новую версию из исходников прямо поверх, в этом случае софт можно будет удалить и как через make uninstall, и через средства пакетного менеджера т.к. в 99.9% случаев расположения и имена файлов сохраняются от версии к версии. А то уж больно хлопотно собирать пакеты когда каждый день обновляешься через svn\git :)
0
torkve #
А еще если автор пакета прописал в нём адрес какой-нибудь VCS, то можно, вообще не напрягаясь, пересобирать пакет, обновляя его средствами dpkg :)
+1
torkve #
Да, именно на сборку :) Ставить отдельную копию пиджина из исходников, в /opt/… фу, да и только.
+1
sitehound #
Ну если он говорит про поддержание (мэинтейнерство) программ, то конечно речь идет о работе с исходниками. А иначе как их дополнять и исправлять.
+1
foe_nix #
Основательный текст, спасибо.
+3
drujebober #
Спасибо. Ждем статью о правильной сборке *.deb пакетов :)
+1
sitehound #
Поддерживаю. Тоже заинтересован с такой статье и в продолжении этой темы.
0
Deepwalker #
Думаю меинтейнер это излишнее заимствование — сопровождающий вполне устоявшийся термин, хорошо отражает суть, и понятно как его писать: )
+2
torkve #
Вы правы, просто ресурсов на эту тематику на русском языке так мало, и я уже так привык к этому термину, пока общался с англоязычными разработчиками, что просто забыл слово «сопровождающий» :)
В следующих частях постараюсь его придерживаться.
+2
k0sh #
По мне так «меинтейнер» самое оно.
+1
Deepwalker #
Понятно, что вопрос с заимствованием всегда был сложным и неоднозначным — мокроступы например, но если слово есть, и используется в переводческой практике, применительно к предметной области, то заимствовать уже незачем — место занято.

Кроме того — ну если уж заимствовать, то может обрусеть вначале надо термину — ну у меня язык так не поворачивается, чтобы этим термином пользоваться, в англоязычном произношении выговорить его гораздо проще. Не забывайте, что в нашем языке пишется близко к произношению.

В любом случае, даже если термин когда либо приживется, будет он узко профессиональным.
+1
torkve #
Да нет, меня совершенно правильно поправили. Термин «сопровождающий пакета» есть и применяется, просто что он, что «мэинтейнер» — не слишком распространены у нас, со всей вытекающей путаницей. Пока термин не распространен — нет чёткого устоявшегося перевода или заимствования. Так что я, пожалуй, будут продвигать всё-таки перевод :)
0
redchrom #
Ну если вдруг тут попадётся майнтэйнер то может сможет заревьюить мой пакет revu.ubuntuwire.com/details.py?package=ypsilon
0
torkve #
В дебиане есть два вида «должностей» — Debian Maintainers — сопровождающие пакеты — и Debian Developers — это как раз самые-самые ответственные за наполнение дистрибутива люди, которые проверяют собранные сопровождающими пакеты и решают, принимать ли их в дистрибутив. В Убунту их роль выполняют, насколько я знаю, как раз Masters of the Universe — MOTU.
Так вот тем, что вы просите, занимаются как раз MOTU и Developers :) Я могу только посмотреть ваш пакет и сказать, что в нем может быть не так, но не вынести решение о принятии/непринятии его в репозиторий :)
0
torkve #
Кстати, о как минимум трёх ошибках вам сообщают прямо на той странице:
# There is at least one common error in this package. Check the lintian file.
# This package has no debian/watch file or get-orig-source rule.
# The Maintainer field is invalid. It has to contain an @ubuntu.com address (usually the Ubuntu MOTU Team's). The packager can leave his/her name as XSBC-Original-Maintainer.
0
torkve #
А еще я только что собрал ваши исходники и получил:
W: ypsilon source: dh-clean-k-is-deprecated
N:
N: This package calls dh_clean -k in its debian/rules file and declares a
N: debhelper compatibility version of at least 7.
N:
N: debhelper 7 deprecated dh_clean -k in favour of dh_prep.
N:
N: Refer to the dh_clean(1) manual page for details.
N:
N: Severity: normal; Certainty: certain
N:
E: ypsilon source: build-depends-on-build-essential build-depends
N:
N: You depend on the build-essential package, which is only a
N:
N:
N:
N: Severity: important; Certainty: certain
N:
W: ypsilon: new-package-should-close-itp-bug
N:
N: This package appears to be the first packaging of a new upstream
N: software package (there is only one changelog entry and the Debian
N: revision is 1), but it does not close any bugs. The initial upload of a
N: new package should close the corresponding ITP bug for that package.
N:
N: This warning can be ignored if the package is not intended for Debian or
N: if it is a split of an existing Debian package.
N:
N: Refer to Debian Developer's Reference section 5.1 (New packages) for
N: details.
N:
N: Severity: normal; Certainty: certain
N:
Finished running lintian.

Файл debian/dirs можно выкинуть, debian при сборке пакета, как правило создаёт сам все нужные каталоги. Этот файл обычно используется, если надо создать пустой каталог, в который пользователь (или еще кто-нибудь) потом будет что-то класть.
Файл debian/rules у вас вообще некрасиво оформлен, его надо переделать и заиспользовать файл install. Я постараюсь рассказать об этом в следующей статье, но, скорее всего, это будет сделано в послеследующей, за следующую всё не успею :)
0
redchrom #
Ну, rules был автоматом сгенерин, так что я поправил только по мелочи.
0
Qiwichupa #
Про сборку пакетов было бы интересно почитать. Вообще было бы круто рассмотреть все возможные способы сборки. От простого (когда для себя надо собрать исходники по-быстрому только чтобы пакетную систему риску не подвергать), к сложному по всем правилам.
0
torkve #
Ну про все возможные я не расскажу, но про сборку от простого бинарного пакета — и до красивой сборки через pbuilder — обязательно :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.