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

[FRAGIL3]

Очень интересная статья, надеюсь количество мэинтейнеров будет расти))
Только вот про подход в Убунте, в последнем абзаце я как-то не очень понял)) Вы на сборку из исходников намекаете что-ли?)

[Scioner]

Скорее всего именно на сборку. Пакетные дистрибутивы должны быть пакетными :)

[FRAGIL3]

Это верно, однако в Ubuntu зачастую ситуация такова, что приходится искать или готовые deb-пакеты, либо собирать руками, так как свежих версий софта в официальном репозитории не дождёшься.
Хотя как вариант можно подключать репозитории с лаунчпада.

[Scioner]

Вариантов, действительно, много. Ланчпад, нагуглить собранный deb-пакет, накрайняк — примитивно собрать пакет самому, каким-нибудь checkinstall'ом.
Это несложно, правда. И дистр остаётся пакетным.

[FRAGIL3]

Про checkinstall не подумал, да)

[Deepwalker]

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

Причем как сделали патченый rdesktop — просто переправили стандартные скрипты сборки этого пакета от Ubuntu. Вот pidgin я думаю тем же методом было бы достаточно просто обточить напильником.

[Deepwalker]

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

Ну и главное — освоив сборку пакетов можно стать сопровождающим: )

[Frosty]

А я применяю такой вариант: сначала ставлю интересующий пакет, а затем накатываю новую версию из исходников прямо поверх, в этом случае софт можно будет удалить и как через make uninstall, и через средства пакетного менеджера т.к. в 99.9% случаев расположения и имена файлов сохраняются от версии к версии. А то уж больно хлопотно собирать пакеты когда каждый день обновляешься через svn\git :)

[torkve]

А еще если автор пакета прописал в нём адрес какой-нибудь VCS, то можно, вообще не напрягаясь, пересобирать пакет, обновляя его средствами dpkg :)

[torkve]

Да, именно на сборку :) Ставить отдельную копию пиджина из исходников, в /opt/… фу, да и только.

[sitehound]

Ну если он говорит про поддержание (мэинтейнерство) программ, то конечно речь идет о работе с исходниками. А иначе как их дополнять и исправлять.

[foe_nix]

Основательный текст, спасибо.

[drujebober]

Спасибо. Ждем статью о правильной сборке *.deb пакетов :)

[sitehound]

Поддерживаю. Тоже заинтересован с такой статье и в продолжении этой темы.

[Deepwalker]

Думаю меинтейнер это излишнее заимствование — сопровождающий вполне устоявшийся термин, хорошо отражает суть, и понятно как его писать: )

[torkve]

Вы правы, просто ресурсов на эту тематику на русском языке так мало, и я уже так привык к этому термину, пока общался с англоязычными разработчиками, что просто забыл слово «сопровождающий» :)
В следующих частях постараюсь его придерживаться.

[k0sh]

По мне так «меинтейнер» самое оно.

[Deepwalker]

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

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

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

[torkve]

Да нет, меня совершенно правильно поправили. Термин «сопровождающий пакета» есть и применяется, просто что он, что «мэинтейнер» — не слишком распространены у нас, со всей вытекающей путаницей. Пока термин не распространен — нет чёткого устоявшегося перевода или заимствования. Так что я, пожалуй, будут продвигать всё-таки перевод :)

[redchrom]

Ну если вдруг тут попадётся майнтэйнер то может сможет заревьюить мой пакет revu.ubuntuwire.com/details.py?package=ypsilon

[torkve]

В дебиане есть два вида «должностей» — Debian Maintainers — сопровождающие пакеты — и Debian Developers — это как раз самые-самые ответственные за наполнение дистрибутива люди, которые проверяют собранные сопровождающими пакеты и решают, принимать ли их в дистрибутив. В Убунту их роль выполняют, насколько я знаю, как раз Masters of the Universe — MOTU.
Так вот тем, что вы просите, занимаются как раз MOTU и Developers :) Я могу только посмотреть ваш пакет и сказать, что в нем может быть не так, но не вынести решение о принятии/непринятии его в репозиторий :)

[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.

[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. Я постараюсь рассказать об этом в следующей статье, но, скорее всего, это будет сделано в послеследующей, за следующую всё не успею :)

[redchrom]

Ну, rules был автоматом сгенерин, так что я поправил только по мелочи.

[Qiwichupa]

Про сборку пакетов было бы интересно почитать. Вообще было бы круто рассмотреть все возможные способы сборки. От простого (когда для себя надо собрать исходники по-быстрому только чтобы пакетную систему риску не подвергать), к сложному по всем правилам.

[torkve]

Ну про все возможные я не расскажу, но про сборку от простого бинарного пакета — и до красивой сборки через pbuilder — обязательно :)