Bug 29822 - Возможность не копировать бинарные пакеты в бранчи
Summary: Возможность не копировать бинарные пакеты в бранчи
Status: CLOSED FIXED
Alias: None
Product: Infrastructure
Classification: Infrastructure
Component: cross-component (show other bugs)
Version: unspecified
Hardware: all Linux
: P3 enhancement
Assignee: Dmitry V. Levin
QA Contact: Andrey Cherepanov
URL: https://www.altlinux.org/%D0%98%D0%B7...
Keywords:
Depends on: 32837
Blocks:
  Show dependency tree
 
Reported: 2014-02-12 14:10 MSK by Zerg
Modified: 2018-11-14 10:02 MSK (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zerg 2014-02-12 14:10:41 MSK
Если сделать возможность один тэг отправлять на сборку в любой бранч, то можно будет убрать возможность копировать бинарные пакеты.
Comment 1 Zerg 2014-02-12 14:11:35 MSK
Так же появится стимул отказываться от srpm в пользу gear.
Comment 2 Zerg 2014-02-12 14:14:22 MSK
Я вижу это в виде
Release: altN%gear_release
, где gear_release -- С60, M70P и ,например, U01 для Сиизфа.
При бранчевании сизифный суффикс увеличивается.
Comment 3 Dmitry V. Levin 2014-02-12 14:36:20 MSK
А в чем, собственно, предложение?
Техническая возможность так делать уже существует.
Comment 4 Sergey V Turchin 2014-02-12 15:40:14 MSK
Я знаю, но руки пока не добрались сделать из нее реальную возможность.

К тому же, add_chengelog на этой "технической возможности" не работает.
Comment 5 Sergey V Turchin 2014-02-12 15:41:53 MSK
(В ответ на комментарий №3)
> А в чем, собственно, предложение?
Как-минимум, в том, чтобы узнать ответные предложения.
Comment 6 Dmitry V. Levin 2014-02-12 16:39:12 MSK
(In reply to comment #5)
> (В ответ на комментарий №3)
> > А в чем, собственно, предложение?
> Как-минимум, в том, чтобы узнать ответные предложения.

Мы когда-то обсуждали, не лучше ли вместо манипулирования RPMTAG_RELEASE'ом внедрить RPMTAG_DISTTAG.
Пришли к выводу о том, что действительно лучше, но в практическую плоскость это обсуждение так и не перешло.
Comment 7 Sergey V Turchin 2014-02-12 16:44:09 MSK
Мне кажется, что лучше это делать только в рамках gear, не трогая rpm.
Хотя, если не сложно, то, конечно, было бы удобнее.
Comment 8 Dmitry V. Levin 2014-02-12 16:55:47 MSK
(In reply to comment #7)
> Мне кажется, что лучше это делать только в рамках gear, не трогая rpm.

В рамках gear при любом выборе, кажется, все уже готово.

> Хотя, если не сложно, то, конечно, было бы удобнее.

Это не только rpm, но и весь остальной софт, который сравнивает релизы пакетов.
Comment 9 Sergey V Turchin 2014-02-12 17:05:14 MSK
(В ответ на комментарий №8)
> В рамках gear при любом выборе, кажется, все уже готово.
1. add_changelog не работает и работающий аналог я не знаю
2. Наличие km-create-tag означает, что в рамках gear нет аналога.
Comment 10 Dmitry V. Levin 2014-02-12 17:18:52 MSK
(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, который используют ядерщики.
Comment 11 Sergey V Turchin 2014-02-12 17:34:31 MSK
(В ответ на комментарий №10)
> В perl-RPM-Source-Editor есть аналог, который не вычисляет спек rpm'ом.
Аналога нет. Нет возможности запустить программу без параметров.
 
> На мой взгляд, в точности наоборот: km-create-tag - это простая надстройка над
> gear, заточенная на изготовление тэгов для kernel-modules-* со специальным
> значением X-gear-specsubst, который используют ядерщики.
Для остальных обычных пакетов такой надстройки нет.
Comment 12 Sergey V Turchin 2014-02-12 17:36:06 MSK
(В ответ на комментарий №11)
> Аналога нет. Нет возможности запустить программу без параметров.
Например, gear-add-chagelog и всё. Спек он знает, где лежит.
Comment 13 Dmitry V. Levin 2014-02-12 17:46:14 MSK
(In reply to comment #11)
> (В ответ на комментарий №10)
> > В perl-RPM-Source-Editor есть аналог, который не вычисляет спек rpm'ом.
> Аналога нет. Нет возможности запустить программу без параметров.

Значит, аналог есть, но без этой возможности; наверное, автор еще не знает, что она кому-то нужна.

> > На мой взгляд, в точности наоборот: km-create-tag - это простая надстройка над
> > gear, заточенная на изготовление тэгов для kernel-modules-* со специальным
> > значением X-gear-specsubst, который используют ядерщики.
> Для остальных обычных пакетов такой надстройки нет.

Видимо, для обычных пакетов X-gear-specsubst не используется, поэтому надстройка не потребовалась.
Comment 14 Sergey V Turchin 2014-02-12 17:50:39 MSK
(В ответ на комментарий №13)
> Значит, аналог есть, но без этой возможности
Аналог означает наличие возможности. Без этой возможности есть очень много "аналогов" ;-)

> Видимо, для обычных пакетов X-gear-specsubst не используется, поэтому
> надстройка не потребовалась.
Я и говорю, нужно добавить универсальную возможность использования X-gear-specsubst в обычных пакетах.
Comment 15 Sergey V Turchin 2014-02-12 17:54:53 MSK
(В ответ на комментарий №14)
> нужно добавить универсальную возможность использования
> X-gear-specsubst в обычных пакетах.
Если еще и без явного указания в rules каких-либо X-gear-specsubst -- было бы замечательно.
Comment 16 Dmitry V. Levin 2014-02-12 18:07:08 MSK
(In reply to comment #14)
> (В ответ на комментарий №13)
> > Значит, аналог есть, но без этой возможности
> Аналог означает наличие возможности. Без этой возможности есть очень много
> "аналогов" ;-)

Главная возможность, реализация которой представляет основную сложность, есть.

> > Видимо, для обычных пакетов X-gear-specsubst не используется, поэтому
> > надстройка не потребовалась.
> Я и говорю, нужно добавить универсальную возможность использования
> X-gear-specsubst в обычных пакетах.

X-gear-specsubst был придуман совсем для другого: чтобы из одного коммита можно было собирать по-разному, используя spec-файл в качестве шаблона, в котором переменные подставляются с помощью правил X-gear-specsubst в тэге.

То, о чем ты завел речь - параметризация спека макросами, зависящими от сборочной среды - к gear отношения не имеет.
Comment 17 Anton Farygin 2014-02-12 18:30:17 MSK
Зерг, а что ты собираешься записывать в changelog пакета при add_changelog и релиза вида: altN%gear_release ?

Ну, для того, что бы это собралось нормально на всех бранчах.
Comment 18 Sergey V Turchin 2014-02-12 18:49:43 MSK
(В ответ на комментарий №17)
> что ты собираешься записывать в changelog пакета
Тоже, что в ядерных модулях, например. Но сейчас там извращаться нужно для использования add_changelog.
Comment 19 Sergey V Turchin 2014-02-12 18:57:54 MSK
(В ответ на комментарий №16)
> Главная возможность, реализация которой представляет
> основную сложность, есть.
Аналог внутренностей не нужен.
Нужен аналог add_changelog без параметров.
Comment 20 Sergey V Turchin 2014-02-12 19:01:24 MSK
(В ответ на комментарий №16)
> параметризация спека макросами, зависящими от
> сборочной среды - к gear отношения не имеет.
Я только за, если она станет не иметь отношения.
Как будет выглядеть 1-е 2 записи в changelog бинарного пакета и как это может выглядеть в spec-файле?
Comment 21 Dmitry V. Levin 2014-02-12 19:03:36 MSK
(In reply to comment #19)
> (В ответ на комментарий №16)
> > Главная возможность, реализация которой представляет
> > основную сложность, есть.
> Аналог внутренностей не нужен.
> Нужен аналог add_changelog без параметров.

Даже у add_changelog есть параметры, ну да ладно, не это главное.

Посказка: пакет называется perl-RPM-Source-Editor, автор дружелюбный, всегда рад реализовать какую-нибудь фичу для пользователей, когда они просят. ;)
Comment 22 Sergey V Turchin 2014-02-12 19:14:18 MSK
(В ответ на комментарий №21)
> пакет называется perl-RPM-Source-Editor, автор дружелюбный, всегда
> рад реализовать какую-нибудь фичу для пользователей, когда они просят. ;)
Это хорошо, но мне лично пока не ясно, как в spec-файле может выглядеть 1-я запись changelog?
Comment 23 Dmitry V. Levin 2014-02-12 19:27:26 MSK
(In reply to comment #20)
> (В ответ на комментарий №16)
> > параметризация спека макросами, зависящими от
> > сборочной среды - к gear отношения не имеет.
> Я только за, если она станет не иметь отношения.
> Как будет выглядеть 1-е 2 записи в changelog бинарного пакета и как это может
> выглядеть в spec-файле?

Это точно не ко мне вопрос, а к автору предложения.  Я сказал, что технически
это предложение реализуемо на одних лишь макросах, без необходимости внесения
изменений в gear, но я не сказал, что мне это предложение нравится.

Когда мы обсуждали RPMTAG_DISTTAG, разумным казался подход, при котором в
%changelog попадали бы только изменения в исходном пакете.  Соответственно, при
пересборке пакета а другой бранч не меняется исходный пакет и запись в
%changelog тоже не добавляется.

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

Мне кажется, что здесь уже началась дискуссия, а дискутировать в багзилле
неудобно.
Comment 24 Zerg 2014-02-12 20:08:11 MSK
(В ответ на комментарий №23)
> если есть
> желание поддерживать сборку бинарных пакетов в разные бранчи из одного и того
> же исходного пакета
Нет. Из одного и того же исходного репозитория.
Тогда BuildRequires можно динамически менять.

Т.е. лично для меня не имеет особого значения содержимое src.rpm .
Comment 25 Zerg 2014-02-12 20:09:46 MSK
(В ответ на комментарий №23)
> > Как будет выглядеть 1-е 2 записи в changelog бинарного пакета и как это может
> > выглядеть в spec-файле?
> 
> Это точно не ко мне вопрос, а к автору предложения.
Т.е. как я скажу, так и будет? ;-)
Comment 26 Zerg 2014-02-12 20:13:15 MSK
(В ответ на комментарий №23)
> дискутировать в багзилле неудобно.
Я не против перебраться в devel.
Comment 27 Michael Shigorin 2014-02-13 14:41:35 MSK
(In reply to comment #0)
> Если сделать возможность один тэг отправлять на сборку в любой бранч,
> то можно будет убрать возможность копировать бинарные пакеты.
Ох уж эти некоторые, всё бы им убрать.

Эта возможность имеет ту пользу, что вместо почти идентичных копий в случаях, когда это уместно, используются не просто идентичные копии, а хардлинки.

Понятно, что и пересборка, и копирование имеют свои плюсы/минусы -- надо просто уметь ими пользоваться, а улучшать можно оба варианта (например, мне давно хочется чего-то вроде "скопировать в t7+p7" для того, что по факту проверено точечным обновлением) без шляпных замашек удушить всё остальное.

И да, пойдёмте в devel@.
Comment 28 Sergey V Turchin 2014-02-13 15:45:32 MSK
(В ответ на комментарий №27)
> Эта возможность имеет ту пользу
Все уже видели эту "пользу" ;-)

> И да, пойдёмте в devel@.
Почему кто-то еще здесь? ;-)
Comment 29 Sergey V Turchin 2016-12-07 10:59:54 MSK
Я сделал 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).
Т.е. если устраивает, этот баг можно закрыть.
Comment 30 Ivan Zakharyaschev 2017-11-10 05:08:02 MSK
Это был бы более удачный путь, чем чисто на макросах. (Потому что тогда в исходной информации для сборки, а именно в теге, содержалось бы всё, чтобы воспроизвести пересборку с сохранением релиза независимо от того, как придумали назвать бранч и т.п. Неожиданные изменения релиза при пересборке в бранче того, что было скопировано с %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 несколько раз, поэтому для большей привлекательности для мейнтейнеров нужна простая команда.
Comment 31 Ivan Zakharyaschev 2017-11-10 05:37:08 MSK
(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)
Comment 32 Anton Farygin 2017-11-10 07:38:22 MSK
Вместо привязки к сборочному окружению ты привязываешься к имени тэга, которое вообще не является обязательным для воспроизведения сборки.

И если уж привязываться, то можно задействовать .gitattributes и export-subst. Хотя и твоё предложение и gitattributes мне не нравится. Мне и ubt не нравится, но он уже работает и оказался вполне удобен для решения простой задачи - без лишних телодвижений собрать одну версию в несколько разных окружений.

Да, релиз меняется - это свойство окружения и требования сборочной системы.
Comment 33 Ivan Zakharyaschev 2017-11-10 12:54:38 MSK
(In reply to comment #32)
> Вместо привязки к сборочному окружению ты привязываешься к имени тэга, которое
> вообще не является обязательным для воспроизведения сборки.

Точнее не к имени тэга, а просто к srpm, в котором больше информации будет о виде релиза, который должен получиться. А srpm однозначно порождается содержимым тэга: сообщением+коммитом.

> И если уж привязываться, то можно задействовать .gitattributes и export-subst.

Но тогда коммитов будет несколько (если я правильно понял идею), если в дереве коммита будет храниться .gitattributes с недостающей информацией о том, как полностью выглядит release.

Несколкьо коммитов для одного и того же изменения -- неудобно, громоздко.

> Да, релиз меняется - это свойство окружения и требования сборочной системы.

Ну в каком-то смысле -- да, требование сборочной системы, согласен. Но реализация через макрос неудачна оказалась; неудобства описывались, например для c8, при копировании таких пакетов: нарушались ожидания относительно пересборки srpm-ов.

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

В принципе, в сборочной среде много чего может повлиять на пакет, и никто не запрещает это менять. Например, версия компилятора. Но это больше влияет на содержимое пакета, чем на его внешний вид: name-version-release... На то, какие будут автозависимости, тоже может что-то повлияет. Автозависимости -- всё-таки больше функция содержимого.

Всё-таки новое мощное предложение (когда не надо менять релиз ради бранча), наверное, наиболее прямое: чтобы вообще не беспокоились из-за этого. Так что прихожу к выводу, что чем пытаться обосновать концептуально, чем лучше альтернативное предложение, лучше приложить усилия к реализации нового предложения.
Comment 34 Sergey V Turchin 2018-11-14 09:39:38 MSK
Работает, как и хотелось.
Comment 35 Sergey V Turchin 2018-11-14 10:02:26 MSK
Уберу зависимолсть, чтоб не спамило.