Собрал один из пакетов, придерживаясь рекомендаций с wiki altlinux.org.
А откуда именно? У нас просто беда, которую упоминал --
есть штуки три "почти написанных" статьи по сборке пакета
с нуля и ни одной завершённой.
Исправлять такое толком получается скорее вдвоём, когда
у одного человека ещё свежо недоумение, а второй понимает,
что именно надо написать для исправления недосказанности.
Как только освоился -- всё, поздно, "и так понятно".
В моём случае порядок чтения статей прошёл следующим образом:
1. В самую первую очередь, чтобы в общих чертах понимать порядок
действий, я посмотрел лекцию
<http://esyr.name/video/uneex/uneex_09_12_16.ogv> Георгия Курячего в
которой демонстрируется весь процесс сборки пакета.
1.1. Отдельно после просмотра внимательно пришлось почитать "Руководство
Hasher"
<https://www.altlinux.org/Hasher/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE>,
там всё написано более чем понятно (по крайней мере у меня все вопросы
отпали после её прочтения на второй или третий раз).
2. Так же по алгоритму сборки пакета я ориентировался на статью "Сборка
пакета с РЕАЛЬНОГО НУЛЯ"
<https://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%B0_%D1%81_%D0%A0%D0%95%D0%90%D0%9B%D0%AC%D0%9D%D0%9E%D0%93%D0%9E_%D0%9D%D0%A3%D0%9B%D0%AF>.
Из этой же статьи позаимствовал подход с tar.gz в .gear/rules
3. Дальше, в попытках осознать смысл своих действий я прочитал "О
стратегии сборки RPM пакетов"
<https://www.altlinux.org/%D0%9E_%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_RPM_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2>.
Здесь я получил представление о подготовке репозитория Git и написании
spec файла. К вопросу о том, почему же я тогда не переделал по
правильному исходный spec? Честно говоря тогда даже мысль такая не
пришла в голову. Подумалось, что разработчику вероятно виднее чем мне,
как должен выглядеть спек. В ретроспективе и после объяснений понимаю
что надо было сесть и внимательно переделать строго с требованиями
документации ALT. Буду знать.
3.1. В статье "О стратегии сборки" так же упоминается tar.gz в секции
"Написание .gear/rules" после второго упоминания такого подхода у меня
не оставалось сомнений, что так и надо делать.
3.2. Момент настройки с созданием gear tags в этой статье, после
прочтения статьи "Сборка пакета с реального нуля" меня немного ввел в
ступор (потому что в первой статье есть упоминание git tag, но не gear).
Но после чтения "Руководство по gear"
<https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_gear>,
и разъяснений @bircoph о том, что подходы к ведению репозитория могут
быть разные, стало более-менее понятно.
Сейчас я бы дополнил этот список крайне внимательным чтением статей
"Spec:Summary" <https://www.altlinux.org/Spec#Summary>, и
"ALT_PAckaging_HOWTO" <https://www.altlinux.org/ALT_Packaging_HOWTO>.
Вероятно, удели я им немного больше внимания, ошибок было бы намного
меньше. Ну и наверное в закладках еще стоит держать
"Spec/Предопределенные макросы"
<https://www.altlinux.org/Spec/%D0%9F%D1%80%D0%B5%D0%B4%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5_%D0%BC%D0%B0%D0%BA%D1%80%D0%BE%D1%81%D1%8B>.
В целом ссылки на большую часть полезных статей уже указаны в "Сборка
пакета с реального нуля". Возможно там не хватает чуть большей
детализации (например по части tar.gz или gear/git tags).
Репозиторий пока оформил на github - https://github.com/burykinne/freelan.
Собранный пакет и src.rpm приложил к письму.
Достаточно было ссылки, ну и собранный пакет точно незачем
-- ведь надо-то проверить, что из исходников собирается. :)
Хорошо, что я не положил собранный пакет с src.rpm туда же в
репозиторий, хотя изначально так и планировал. :)
По процессу сборки вроде бы всё было понятно, но, возможно,
не всё было понято правильно.
Сразу бросился в глаза freelan-2.3.tar.gz -- подход с gear
не предназначен для хранения для архивов, предполагается,
что они-то как раз распаковываются в основную ветку либо
по своим, но чтоб работал осмысленным образом git diff:
http://bugzilla.altlinux.org/show_bug.cgi?id=36074#c12
Здесь важно, по возможности прочтите обсуждение там.
Надо понять, что обусловило создание коммита
b4594ab7afbb51aa6c8e03e5bfd8618df4bf7289 --
и исправить документацию.
Как я писал выше, подход с tar.gz мною был позаимствован с Wiki.
После прочтения обсуждения (в частности
https://bugzilla.altlinux.org/show_bug.cgi?id=36074#c22) сделал вывод
что так делать не следует (за исключением частных случаев). Хотя
указание этого метода в двух статьях меня всё таки смущает.
Плюс взял на заметку
https://bugzilla.altlinux.org/show_bug.cgi?id=36074#c34 . У меня в
коммитах такая же ошибка. Тоже буду иметь ввиду.
freelan-2.3-alt-make-fix.patch я бы не делал, т.к. "?="
переводится как "задать, если не задано" -- т.е. вызов
make PRODUCT_PREFIX=/ PRODUCT_BIN_PREFIX=%_usr
даст тот же результат, но не потребует обновлять патч
при изменении контекста в Makefile.
Любопытно, я пробовал сделать так, перед тем, как создавать патч. Но оно
упорно не хотело собираться с путями, которые мне были нужны. Потом я
подсмотрел как это сделано в deb пакете, там был патч, и я подумал что
наверное так более правильно. И собственно говоря сделал его, с помощью
статьи https://www.altlinux.org/PatchHowto
P.S. Сейчас в тестовой ветке попробовал еще раз пересобрать с
PRUDUCT_PREFIX... - получилось без проблем с нужными путями. Жаль не
сохранил ветку с ранними экспериментами, на посмотреть что же я тогда не
правильно сделал там.
Спек тоже "грязненький", как по альтовым (и моим) меркам
-- непонятно, зачем sebastien.vincent@ решил вручную
выставлять %name/%version/%release, когда их определяет
сам rpmbuild на основании Name:/Version:/Release:, ну да
это уж разве что ему пересказать. Прилагаю почти такой,
как сделал бы сам (не стал эстетствовать с висячими "a"
в %description, это бы добавило шума в патч); разберём:
Применил присланный патч и отправил в репозиторий. К документации впредь
буду относиться более внимательно. В частности к "ALT_PAckaging_HOWTO"
<https://www.altlinux.org/ALT_Packaging_HOWTO>. Надеюсь с следующим
спеком всё таки справлюсь самостоятельно :)
Из дальнейших улучшений -- я бы сделал ещё initscript
по мотивам /etc/init.d/template, но давайте к такому
вернёмся уже после прохождения пакета в сизиф.
Постараюсь сделать initscript до прохождения пакета в сизиф, чтобы туда
он максимально законченным попал.
_______________________________________________
devel-newbies mailing list
devel-newbies@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/devel-newbies
