Если сделать возможность один тэг отправлять на сборку в любой бранч, то можно будет убрать возможность копировать бинарные пакеты.
Так же появится стимул отказываться от srpm в пользу gear.
Я вижу это в виде Release: altN%gear_release , где gear_release -- С60, M70P и ,например, U01 для Сиизфа. При бранчевании сизифный суффикс увеличивается.
А в чем, собственно, предложение? Техническая возможность так делать уже существует.
Я знаю, но руки пока не добрались сделать из нее реальную возможность. К тому же, add_chengelog на этой "технической возможности" не работает.
(В ответ на комментарий №3) > А в чем, собственно, предложение? Как-минимум, в том, чтобы узнать ответные предложения.
(In reply to comment #5) > (В ответ на комментарий №3) > > А в чем, собственно, предложение? > Как-минимум, в том, чтобы узнать ответные предложения. Мы когда-то обсуждали, не лучше ли вместо манипулирования RPMTAG_RELEASE'ом внедрить RPMTAG_DISTTAG. Пришли к выводу о том, что действительно лучше, но в практическую плоскость это обсуждение так и не перешло.
Мне кажется, что лучше это делать только в рамках gear, не трогая rpm. Хотя, если не сложно, то, конечно, было бы удобнее.
(In reply to comment #7) > Мне кажется, что лучше это делать только в рамках gear, не трогая rpm. В рамках gear при любом выборе, кажется, все уже готово. > Хотя, если не сложно, то, конечно, было бы удобнее. Это не только rpm, но и весь остальной софт, который сравнивает релизы пакетов.
(В ответ на комментарий №8) > В рамках gear при любом выборе, кажется, все уже готово. 1. add_changelog не работает и работающий аналог я не знаю 2. Наличие km-create-tag означает, что в рамках gear нет аналога.
(In reply to comment #9) > (В ответ на комментарий №8) > > В рамках gear при любом выборе, кажется, все уже готово. > 1. add_changelog не работает и работающий аналог я не знаю В perl-RPM-Source-Editor есть аналог, который не вычисляет спек rpm'ом. > 2. Наличие km-create-tag означает, что в рамках gear нет аналога. На мой взгляд, в точности наоборот: km-create-tag - это простая надстройка над gear, заточенная на изготовление тэгов для kernel-modules-* со специальным значением X-gear-specsubst, который используют ядерщики.
(В ответ на комментарий №10) > В perl-RPM-Source-Editor есть аналог, который не вычисляет спек rpm'ом. Аналога нет. Нет возможности запустить программу без параметров. > На мой взгляд, в точности наоборот: km-create-tag - это простая надстройка над > gear, заточенная на изготовление тэгов для kernel-modules-* со специальным > значением X-gear-specsubst, который используют ядерщики. Для остальных обычных пакетов такой надстройки нет.
(В ответ на комментарий №11) > Аналога нет. Нет возможности запустить программу без параметров. Например, gear-add-chagelog и всё. Спек он знает, где лежит.
(In reply to comment #11) > (В ответ на комментарий №10) > > В perl-RPM-Source-Editor есть аналог, который не вычисляет спек rpm'ом. > Аналога нет. Нет возможности запустить программу без параметров. Значит, аналог есть, но без этой возможности; наверное, автор еще не знает, что она кому-то нужна. > > На мой взгляд, в точности наоборот: km-create-tag - это простая надстройка над > > gear, заточенная на изготовление тэгов для kernel-modules-* со специальным > > значением X-gear-specsubst, который используют ядерщики. > Для остальных обычных пакетов такой надстройки нет. Видимо, для обычных пакетов X-gear-specsubst не используется, поэтому надстройка не потребовалась.
(В ответ на комментарий №13) > Значит, аналог есть, но без этой возможности Аналог означает наличие возможности. Без этой возможности есть очень много "аналогов" ;-) > Видимо, для обычных пакетов X-gear-specsubst не используется, поэтому > надстройка не потребовалась. Я и говорю, нужно добавить универсальную возможность использования X-gear-specsubst в обычных пакетах.
(В ответ на комментарий №14) > нужно добавить универсальную возможность использования > X-gear-specsubst в обычных пакетах. Если еще и без явного указания в rules каких-либо X-gear-specsubst -- было бы замечательно.
(In reply to comment #14) > (В ответ на комментарий №13) > > Значит, аналог есть, но без этой возможности > Аналог означает наличие возможности. Без этой возможности есть очень много > "аналогов" ;-) Главная возможность, реализация которой представляет основную сложность, есть. > > Видимо, для обычных пакетов X-gear-specsubst не используется, поэтому > > надстройка не потребовалась. > Я и говорю, нужно добавить универсальную возможность использования > X-gear-specsubst в обычных пакетах. X-gear-specsubst был придуман совсем для другого: чтобы из одного коммита можно было собирать по-разному, используя spec-файл в качестве шаблона, в котором переменные подставляются с помощью правил X-gear-specsubst в тэге. То, о чем ты завел речь - параметризация спека макросами, зависящими от сборочной среды - к gear отношения не имеет.
Зерг, а что ты собираешься записывать в changelog пакета при add_changelog и релиза вида: altN%gear_release ? Ну, для того, что бы это собралось нормально на всех бранчах.
(В ответ на комментарий №17) > что ты собираешься записывать в changelog пакета Тоже, что в ядерных модулях, например. Но сейчас там извращаться нужно для использования add_changelog.
(В ответ на комментарий №16) > Главная возможность, реализация которой представляет > основную сложность, есть. Аналог внутренностей не нужен. Нужен аналог add_changelog без параметров.
(В ответ на комментарий №16) > параметризация спека макросами, зависящими от > сборочной среды - к gear отношения не имеет. Я только за, если она станет не иметь отношения. Как будет выглядеть 1-е 2 записи в changelog бинарного пакета и как это может выглядеть в spec-файле?
(In reply to comment #19) > (В ответ на комментарий №16) > > Главная возможность, реализация которой представляет > > основную сложность, есть. > Аналог внутренностей не нужен. > Нужен аналог add_changelog без параметров. Даже у add_changelog есть параметры, ну да ладно, не это главное. Посказка: пакет называется perl-RPM-Source-Editor, автор дружелюбный, всегда рад реализовать какую-нибудь фичу для пользователей, когда они просят. ;)
(В ответ на комментарий №21) > пакет называется perl-RPM-Source-Editor, автор дружелюбный, всегда > рад реализовать какую-нибудь фичу для пользователей, когда они просят. ;) Это хорошо, но мне лично пока не ясно, как в spec-файле может выглядеть 1-я запись changelog?
(In reply to comment #20) > (В ответ на комментарий №16) > > параметризация спека макросами, зависящими от > > сборочной среды - к gear отношения не имеет. > Я только за, если она станет не иметь отношения. > Как будет выглядеть 1-е 2 записи в changelog бинарного пакета и как это может > выглядеть в spec-файле? Это точно не ко мне вопрос, а к автору предложения. Я сказал, что технически это предложение реализуемо на одних лишь макросах, без необходимости внесения изменений в gear, но я не сказал, что мне это предложение нравится. Когда мы обсуждали RPMTAG_DISTTAG, разумным казался подход, при котором в %changelog попадали бы только изменения в исходном пакете. Соответственно, при пересборке пакета а другой бранч не меняется исходный пакет и запись в %changelog тоже не добавляется. Обоснование этого подхода было примерно следующим: количество и характер сборок из исходного пакета никак не влияют на этот исходный пакет, если только не записывать эту информацию в сам исходный пакет. Соответственно, если есть желание поддерживать сборку бинарных пакетов в разные бранчи из одного и того же исходного пакета, то факт этих сборок не должен в нем отражаться. Мне кажется, что здесь уже началась дискуссия, а дискутировать в багзилле неудобно.
(В ответ на комментарий №23) > если есть > желание поддерживать сборку бинарных пакетов в разные бранчи из одного и того > же исходного пакета Нет. Из одного и того же исходного репозитория. Тогда BuildRequires можно динамически менять. Т.е. лично для меня не имеет особого значения содержимое src.rpm .
(В ответ на комментарий №23) > > Как будет выглядеть 1-е 2 записи в changelog бинарного пакета и как это может > > выглядеть в spec-файле? > > Это точно не ко мне вопрос, а к автору предложения. Т.е. как я скажу, так и будет? ;-)
(В ответ на комментарий №23) > дискутировать в багзилле неудобно. Я не против перебраться в devel.
(In reply to comment #0) > Если сделать возможность один тэг отправлять на сборку в любой бранч, > то можно будет убрать возможность копировать бинарные пакеты. Ох уж эти некоторые, всё бы им убрать. Эта возможность имеет ту пользу, что вместо почти идентичных копий в случаях, когда это уместно, используются не просто идентичные копии, а хардлинки. Понятно, что и пересборка, и копирование имеют свои плюсы/минусы -- надо просто уметь ими пользоваться, а улучшать можно оба варианта (например, мне давно хочется чего-то вроде "скопировать в t7+p7" для того, что по факту проверено точечным обновлением) без шляпных замашек удушить всё остальное. И да, пойдёмте в devel@.
(В ответ на комментарий №27) > Эта возможность имеет ту пользу Все уже видели эту "пользу" ;-) > И да, пойдёмте в devel@. Почему кто-то еще здесь? ;-)
Я сделал rpm-build-ubt, с которым можно Release: alt1%ubt BuildRequires(pre): rpm-build-ubt ubt-addchangelog -e '- new version' pkg.spec gear-create-tag , который собирается в любой бранч, в котором есть соотв. rpm-macros-ubt(сейчас в p6 t6 p7 t7 p8 sisyphus). Т.е. если устраивает, этот баг можно закрыть.
Это был бы более удачный путь, чем чисто на макросах. (Потому что тогда в исходной информации для сборки, а именно в теге, содержалось бы всё, чтобы воспроизвести пересборку с сохранением релиза независимо от того, как придумали назвать бранч и т.п. Неожиданные изменения релиза при пересборке в бранче того, что было скопировано с %ubt, оказались очень неудобными.) (In reply to comment #14) > Я и говорю, нужно добавить универсальную возможность использования > X-gear-specsubst в обычных пакетах. Такая возможность есть, ничего специального не надо. Работает на практике; вот пример. Один и тот же коммит в двух разных тегах: $ cd /gears/p/python3-module-enchant.git/ $ git --no-pager show 1.6.5-alt5-py3 --pretty=short -s tag 1.6.5-alt5-py3 Tagger: Ivan Zakharyaschev <imz@altlinux.org> X-gear-specsubst: pyver=3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEABECAAYFAlcLxjoACgkQC3P/ewn3V3ggDQCfbF9LHOIivyaQ7UMauEAWFUgg atUAnjj20gqTxvJ9SY5z3abBxHVMiktC =VhDA -----END PGP SIGNATURE----- commit af0227c2eb9f33d986cb5eff279a45f82728dda6 Author: Ivan Zakharyaschev <imz@altlinux.org> 1.6.5-alt5 - (NMU) rebuild with rpm-build-python3-0.1.10 (for new-style python3(*) reqs) and with python3-3.5 (for byte-compilation). $ cd /gears/p/python-module-enchant.git/ $ git --no-pager show 1.6.5-alt5 --pretty=short -s tag 1.6.5-alt5 Tagger: Ivan Zakharyaschev <imz@altlinux.org> X-gear-specsubst: pyver= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEABECAAYFAlcLxlYACgkQC3P/ewn3V3i2eACeMCvYEadY7k0/pSFJABkJtasW KSoAnAo/aY/+wrFX4XYefsUZqzyEMtJe =x9Fx -----END PGP SIGNATURE----- commit af0227c2eb9f33d986cb5eff279a45f82728dda6 Author: Ivan Zakharyaschev <imz@altlinux.org> 1.6.5-alt5 - (NMU) rebuild with rpm-build-python3-0.1.10 (for new-style python3(*) reqs) and with python3-3.5 (for byte-compilation). ( http://git.altlinux.org/gears/p/python3-module-enchant.git?p=python3-module-enchant.git;a=tag;h=f550ffade9d8468573c2ddf4c0ef78b83a6c595c и http://git.altlinux.org/gears/p/python-module-enchant.git?p=python-module-enchant.git;a=tag;h=d9b7113acf963d405434054b9c01583ddb9f9795 ) В общем, можно собирать из одного коммита в один или разные бранчи (с разными добавками в номер релиза при желании), но нужно поставить несколько тегов не очень сложных, которые сохранят отличающиеся значения под именем параметра. Упрощает вид истории Git, ведь получается без постоянных переплетений. Это, конечно, не так круто, как новое предложение собирать из одного srpm-а (без дополнительных изменений, и получать пакеты, которые будут годиться как разные, для одного или разных бранчей). А преимущество (повторю, с чего начал) перед %ubt, приезжающего из сборочной среды, в том, что всё задано и сохранено в теге. (In reply to comment #10) > На мой взгляд, в точности наоборот: km-create-tag - это простая надстройка над > gear, заточенная на изготовление тэгов для kernel-modules-* со специальным > значением X-gear-specsubst, который используют ядерщики. Для удобства и быстроты создания нескольких тегов (для разных бранчей) нужно просто добавить простую надстройку общего назначения над git tag -s/gear-create-tag, которая будет заполнять тег присваиванием правильного значения выбранному имени параметра перед сборкой в определённый бранч (или сразу много тегов для нескольких бранчей). Само по себе действие простое, и формат простой, просто немного времени отнимает писать вручную tag message несколько раз, поэтому для большей привлекательности для мейнтейнеров нужна простая команда.
(In reply to comment #10) > > 1. add_changelog не работает и работающий аналог я не знаю > > В perl-RPM-Source-Editor есть аналог, который не вычисляет спек rpm'ом. Что касается генерации первой строчки changelog-а, то вот ещё штука, которая умеет и с которой можно брать пример (если не напрямую использовать): python-module-enchant $ gear-changelog --no-rules * Fri Nov 10 2017 Ivan Zakharyaschev <imz@altlinux.org> 1.6.5-alt5@pyver@ -- здесь для эксперимента добавил в Release этот параметр. А вот gear --describe жалуется: python-module-enchant $ gear --describe gear: specsubst directive requires a tag Вставлять далее можно с помощью paste_changelog (или echo News | EDITOR=paste_changelog gear-edit-spec)
Вместо привязки к сборочному окружению ты привязываешься к имени тэга, которое вообще не является обязательным для воспроизведения сборки. И если уж привязываться, то можно задействовать .gitattributes и export-subst. Хотя и твоё предложение и gitattributes мне не нравится. Мне и ubt не нравится, но он уже работает и оказался вполне удобен для решения простой задачи - без лишних телодвижений собрать одну версию в несколько разных окружений. Да, релиз меняется - это свойство окружения и требования сборочной системы.
(In reply to comment #32) > Вместо привязки к сборочному окружению ты привязываешься к имени тэга, которое > вообще не является обязательным для воспроизведения сборки. Точнее не к имени тэга, а просто к srpm, в котором больше информации будет о виде релиза, который должен получиться. А srpm однозначно порождается содержимым тэга: сообщением+коммитом. > И если уж привязываться, то можно задействовать .gitattributes и export-subst. Но тогда коммитов будет несколько (если я правильно понял идею), если в дереве коммита будет храниться .gitattributes с недостающей информацией о том, как полностью выглядит release. Несколкьо коммитов для одного и того же изменения -- неудобно, громоздко. > Да, релиз меняется - это свойство окружения и требования сборочной системы. Ну в каком-то смысле -- да, требование сборочной системы, согласен. Но реализация через макрос неудачна оказалась; неудобства описывались, например для c8, при копировании таких пакетов: нарушались ожидания относительно пересборки srpm-ов. Как сформулировать, что здесь "нарушается", я толком не знаю, чтобы огородить нас от таких проблем. В принципе, в сборочной среде много чего может повлиять на пакет, и никто не запрещает это менять. Например, версия компилятора. Но это больше влияет на содержимое пакета, чем на его внешний вид: name-version-release... На то, какие будут автозависимости, тоже может что-то повлияет. Автозависимости -- всё-таки больше функция содержимого. Всё-таки новое мощное предложение (когда не надо менять релиз ради бранча), наверное, наиболее прямое: чтобы вообще не беспокоились из-за этого. Так что прихожу к выводу, что чем пытаться обосновать концептуально, чем лучше альтернативное предложение, лучше приложить усилия к реализации нового предложения.
Работает, как и хотелось.
Уберу зависимолсть, чтоб не спамило.
