Это в убунту, и там только в определенный момент идёт фриз новых версий, а принимаются только исправления найденных багов. В дебиане то же самое происходит со stable версией, которая выпускается раз в ~2 года, а в unstable у меня пакеты каждую неделю обновляются :)
Понимаете, если пользователь сделает echo 1 > /proc/..., то он всё равно как минимум включит роутинг на своём шлюзе, а потом, со временем, при попытке оптимизации своих скриптов или просто исследовании /etc наткнется на упоминание нужной переменной в sysctl.conf и разберется, как сделать лучше. Даже если у него не сработает пример из руководства — он сможет залезть в ман и найти, что в руководстве оказалось неверным применительно к новой версии. В любом случае материал мана будет восприниматься гораздо лучше, а не как абстрактный набор каких-то команд, не связанных в стройную последовательность. Отсутствие руководств вообще — это хуже, чем наличие устаревших руководств.
Я хочу, чтобы для сборки пакетов не надо было специального созревания. Чтобы пользователь прочитал краткое руководство и сразу сел их собирать. Вот когда при заливке в репозиторий ему скажут: «тут у вас бага, поправьте», он уже залезет в официальное руководство и восполнит пробелы. И это ему будет гораздо проще, поскольку он уже будет понимать процесс сборки, а не теряться в томах Policy.
Ну, для пользователя проще всего будет поставить программу откуда-нибудь из репозитория. В убунту с его ежедневным поиском обновлений это вообще не вызовет никаких проблем — как только залили новую версию в репозиторий — на следующий день она уже предлагается пользователю для установки, только нажми кнопочку «установить». А архив надо откуда-то скачать, распаковать, поставить…
Так что оптимальным вариантом будет естественно собрать пакет и пропихнуть в офф. репозиторий. Для изучения особенностей питоновских пакетов — опять же смотрить Python Policy плюс скачайте src-пакет еще какой-нибудь программы на питоне, которую уже добавили в репозиторий. Будет намного проще :)
Да, а для питона есть какой-то свой аналог перлового CPAN и утилита checkinstall, тут OldFornit совершенно прав.
И отдельно можете почитать Python Policy, описывающее особые правила, применяемые в Debian к питону и его модулям.
Всё будет, я только начал :) Просто чтобы рассказывать именно об упаковке, надо сначала представлять, что нам из этого может понадобиться и как этим всем пользоваться :) В следующий раз будет как раз уже про сборку пакетов.
А еще вообще всё написано в манах и исходниках программ, достаточно только покурить их с недельку. А еще есть толстый красивый документ Debian Policy, освещающий все аспекты бытия и листы рассылки debian-devel и debian-mentors для тех, кому всех аспектов бытия почему-то не хватило.
И чтобы всё это воскурить, надо потратить кучу времени, разбираясь, где с чего начать, как всем этим заниматься, что куда писать и к кому собственно обращаться для добавления пакета в репозиторий, ну и так далее. Я знаю это по собственному опыту, потому что начинал я этим заниматься сам, а когда решил всё-таки включить пакет в официальный репозиторий Debian, то всплыло столько интересных моментов, что допиливаю я его до сих пор. И спасибо одному российскому Debian Developer'у, который потратил много времени, рассказывая мне все тонкости.
Всем известно, что у Убунту, наверное, самое большое и мощное коммьюнити, но при этом подавляющее число пользователей не являются гиками и специалистами вообще. Поэтому я хочу составить доступное удобное руководство, которое позволило бы разобраться со всем необходимым, не привлекая толпы посторонних людей, и не изучая страницы англоязычной переписки на debian-devel.
P.s. И, кстати говоря, русская версия maint-guide, когда я ее последний раз видел, была очень сильно устаревшей и неполной по сравнению с нормальной английской.
А вы попробуйте, dch -i, как из примера видно, определяет, что вы не мэинтейнер и увеличивает версию в рекомендуемом формате: до 2.4-16.1. Если почитать приведенный вывод lintian, то там об этом даже явно написано:
N: A source NMU should have a Debian revision of "-x.x" (or "+nmuX" for a
N: native package). This is to prevent stealing version numbers from the
N: maintainer.
Собственно мы исправляли предложенный вариант и неправильно увеличивали номер версии с единственной целью — продемонстрировать, как работает и ругается lintian.
А еще я только что собрал ваши исходники и получил:
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. Я постараюсь рассказать об этом в следующей статье, но, скорее всего, это будет сделано в послеследующей, за следующую всё не успею :)
Кстати, о как минимум трёх ошибках вам сообщают прямо на той странице:
# 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.
В дебиане есть два вида «должностей» — Debian Maintainers — сопровождающие пакеты — и Debian Developers — это как раз самые-самые ответственные за наполнение дистрибутива люди, которые проверяют собранные сопровождающими пакеты и решают, принимать ли их в дистрибутив. В Убунту их роль выполняют, насколько я знаю, как раз Masters of the Universe — MOTU.
Так вот тем, что вы просите, занимаются как раз MOTU и Developers :) Я могу только посмотреть ваш пакет и сказать, что в нем может быть не так, но не вынести решение о принятии/непринятии его в репозиторий :)
Это да, но я и не говорю, что наша образовательная система совершенна :) Лекцию Столлмана я когда-то именно по этой причине пропустил — сдавал в это время свой практикум.
1) при заявлении обычно пишется волшебная строчка «сдача курса идёт не в ущерб основному обучению на… факультете» :) Я считаю это правильным, ведь согласитесь, если вы идёте учиться на программиста, с чего вдруг вы должны выкидывать профильные предметы с целью прослушать курс латыни на филфаке? Хотите дополнительно — пожалуйста.
2) Чего нет — того нет :)
Понимаете, я согласен, что кому-то хочется заниматься чисто исследованиями. Но здесь ситуация та же самая, что и в коммерции: есть Вася — талантливый физик, он копошится в микросхемах, потому что он это умеет и ему это интересно, есть Петр Петрович — заведующий лабораторией, который организует всю работу и всех координирует, и есть приглашенная Петром Петровичем девочка Катя из фирмы «Руссиш Микросхемас Лтд.», которая немножко разбирается в том, чем занимается Вася, отлично понимает, что нужно фирме Руссиш Микросхемас и может помочь в продвижении разработок и оплате труда Васи с Петром Петровичем. Впрочем, роль девочки Кати может выполнять и сам Петр Петрович, который будет впаривать Васин труд в нужную фирму. Лаборатория никогда не является замкнутой системой, всегда есть завлаб — организационная помимо всего прочего должность. Завлаб так или иначе должен выбивать нужное снабжение лаборатории, писать отчёты и заниматься прочей ненаучной ересью, поэтому коммерческое продвижение продукции для него будет не более страшной деятельностью.
А мы с вами, как и талантливый физик Вася, будем в это время что-нибудь исследовать. :)
На самом деле, такая ситуация, к счастью, не во всех вузах. Например, в нашем самом-большом-вузе-страны без каких-либо проблем можно прослушать курс на любом факультете, написать заявление в учебную часть и, сдав его дополнительно, получить себе лишнюю запись в диплом.
Более того, если договориться в своей лаборатории и если это нужно для научной работы, то можно ходить на спецкурсы на другой факультет и засчитывать их как профильные. В отличие от первого варианта, это нераспространенное явление, да, и требует значительных усилий, но всё-таки такое возможно, знаю по своему опыту.
С проблемой же оплаты труда вопрос тоже интересный. Я считаю очень показательным случай, когда одна кафедра нашего факультета, существовавшая чисто номинально в подвале, исключительно своими усилиями сумела раскрутиться настолько, что сумели выбить себе отдельный корпус, на свои деньги полностью его отремонтировали и обставили новейшим оборудованием, организовали научную и коммерческую деятельность и отличный учебный курс для студентов. Иными словами, хорошая наука — это та наука, за которую вам будут готовы платить, к сожалению, у нас в стране это не все еще поняли. Если правильно поставить процесс, то можно заниматься интересными и полезными разработками даже у себя в университете и получать деньги от промышленников, которые заинтересованы в данных разработках. А можно уныло копошиться у себя в лаборатории и жаловаться, что государство денег не даёт, такое у нас тоже, как ни странно есть. Наука ценна, когда она имеет практическую реализацию, а не столбик бесполезных формул на бумаге и статью в ВАКовском журнале.
Да нет, меня совершенно правильно поправили. Термин «сопровождающий пакета» есть и применяется, просто что он, что «мэинтейнер» — не слишком распространены у нас, со всей вытекающей путаницей. Пока термин не распространен — нет чёткого устоявшегося перевода или заимствования. Так что я, пожалуй, будут продвигать всё-таки перевод :)
Вы правы, просто ресурсов на эту тематику на русском языке так мало, и я уже так привык к этому термину, пока общался с англоязычными разработчиками, что просто забыл слово «сопровождающий» :)
В следующих частях постараюсь его придерживаться.
Я хочу, чтобы для сборки пакетов не надо было специального созревания. Чтобы пользователь прочитал краткое руководство и сразу сел их собирать. Вот когда при заливке в репозиторий ему скажут: «тут у вас бага, поправьте», он уже залезет в официальное руководство и восполнит пробелы. И это ему будет гораздо проще, поскольку он уже будет понимать процесс сборки, а не теряться в томах Policy.
Так что оптимальным вариантом будет естественно собрать пакет и пропихнуть в офф. репозиторий. Для изучения особенностей питоновских пакетов — опять же смотрить Python Policy плюс скачайте src-пакет еще какой-нибудь программы на питоне, которую уже добавили в репозиторий. Будет намного проще :)
И отдельно можете почитать Python Policy, описывающее особые правила, применяемые в Debian к питону и его модулям.
И чтобы всё это воскурить, надо потратить кучу времени, разбираясь, где с чего начать, как всем этим заниматься, что куда писать и к кому собственно обращаться для добавления пакета в репозиторий, ну и так далее. Я знаю это по собственному опыту, потому что начинал я этим заниматься сам, а когда решил всё-таки включить пакет в официальный репозиторий Debian, то всплыло столько интересных моментов, что допиливаю я его до сих пор. И спасибо одному российскому Debian Developer'у, который потратил много времени, рассказывая мне все тонкости.
Всем известно, что у Убунту, наверное, самое большое и мощное коммьюнити, но при этом подавляющее число пользователей не являются гиками и специалистами вообще. Поэтому я хочу составить доступное удобное руководство, которое позволило бы разобраться со всем необходимым, не привлекая толпы посторонних людей, и не изучая страницы англоязычной переписки на debian-devel.
P.s. И, кстати говоря, русская версия maint-guide, когда я ее последний раз видел, была очень сильно устаревшей и неполной по сравнению с нормальной английской.
Сейчас исправлю.
Собственно мы исправляли предложенный вариант и неправильно увеличивали номер версии с единственной целью — продемонстрировать, как работает и ругается lintian.
Файл debian/dirs можно выкинуть, debian при сборке пакета, как правило создаёт сам все нужные каталоги. Этот файл обычно используется, если надо создать пустой каталог, в который пользователь (или еще кто-нибудь) потом будет что-то класть.
Файл debian/rules у вас вообще некрасиво оформлен, его надо переделать и заиспользовать файл install. Я постараюсь рассказать об этом в следующей статье, но, скорее всего, это будет сделано в послеследующей, за следующую всё не успею :)
# 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.
Так вот тем, что вы просите, занимаются как раз MOTU и Developers :) Я могу только посмотреть ваш пакет и сказать, что в нем может быть не так, но не вынести решение о принятии/непринятии его в репозиторий :)
2) Чего нет — того нет :)
Понимаете, я согласен, что кому-то хочется заниматься чисто исследованиями. Но здесь ситуация та же самая, что и в коммерции: есть Вася — талантливый физик, он копошится в микросхемах, потому что он это умеет и ему это интересно, есть Петр Петрович — заведующий лабораторией, который организует всю работу и всех координирует, и есть приглашенная Петром Петровичем девочка Катя из фирмы «Руссиш Микросхемас Лтд.», которая немножко разбирается в том, чем занимается Вася, отлично понимает, что нужно фирме Руссиш Микросхемас и может помочь в продвижении разработок и оплате труда Васи с Петром Петровичем. Впрочем, роль девочки Кати может выполнять и сам Петр Петрович, который будет впаривать Васин труд в нужную фирму. Лаборатория никогда не является замкнутой системой, всегда есть завлаб — организационная помимо всего прочего должность. Завлаб так или иначе должен выбивать нужное снабжение лаборатории, писать отчёты и заниматься прочей ненаучной ересью, поэтому коммерческое продвижение продукции для него будет не более страшной деятельностью.
А мы с вами, как и талантливый физик Вася, будем в это время что-нибудь исследовать. :)
Более того, если договориться в своей лаборатории и если это нужно для научной работы, то можно ходить на спецкурсы на другой факультет и засчитывать их как профильные. В отличие от первого варианта, это нераспространенное явление, да, и требует значительных усилий, но всё-таки такое возможно, знаю по своему опыту.
С проблемой же оплаты труда вопрос тоже интересный. Я считаю очень показательным случай, когда одна кафедра нашего факультета, существовавшая чисто номинально в подвале, исключительно своими усилиями сумела раскрутиться настолько, что сумели выбить себе отдельный корпус, на свои деньги полностью его отремонтировали и обставили новейшим оборудованием, организовали научную и коммерческую деятельность и отличный учебный курс для студентов. Иными словами, хорошая наука — это та наука, за которую вам будут готовы платить, к сожалению, у нас в стране это не все еще поняли. Если правильно поставить процесс, то можно заниматься интересными и полезными разработками даже у себя в университете и получать деньги от промышленников, которые заинтересованы в данных разработках. А можно уныло копошиться у себя в лаборатории и жаловаться, что государство денег не даёт, такое у нас тоже, как ни странно есть. Наука ценна, когда она имеет практическую реализацию, а не столбик бесполезных формул на бумаге и статью в ВАКовском журнале.
В следующих частях постараюсь его придерживаться.