On Mon, May 31, 2021 at 04:28:31PM +0300, Andrey Savchenko wrote: > On Mon, 31 May 2021 15:53:25 +0300 Arseny Maslennikov wrote: > > On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote: > > > On 31.05.2021 15:09, Sergey V Turchin wrote: > > > > > > > Я знаю про это задание, но в этом изменении слишком кардинально меняется > > > содержимое макроса, что вряд ли приемлемо для stable репозитория. > > > > > > Т.е. - условно говоря если раньше макрос ничего не делал, то теперь делает. > > > > В 272559 все пакеты, явно использовавшие %cmake_install в его > > (бесполезном, кмк) старом значении, исправлены. > > > > > > Да и с BUILD непонятно зачем сделано. Было бы интересно услышать комментарии > > > по этому поводу. > > > > Одна из преследуемых целей — спеки не должны зависеть от конкретного > > значения %_cmake__builddir, которое они не выставили явно, поэтому их > > исправление там, где в них явно про некоторые файлы написано BUILD/*, > > всё равно планировалось. Изменив BUILD на что-то ещё, легко узнать > > список всех пакетов, нарушающих этот принцип. > > > > Файловые объекты с "простым" именем BUILD, build, ... с заметной долей > > вероятности могут уже присутствовать в > > /usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний > > неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на > > `mkdir %_cmake__builddir'. > > mkdir -p решает эту проблему в 99.999% случаев (теоретически > возможно, что BUILD — это файл или используетс апстримом для иных > нужд, но на практике такое вряд ли встречается). Я встречал 2 раза, это уже больше, чем 0.001%. :) Например, в проектах на google c++-стеке встречаются сборочные скрипты для Bazel, точка входа в которые называется именно BUILD. В одном пакете я даже видел ln -s build BUILD. > > > В долгосрочной перспективе нам уместно > > (медленно, но верно) стремиться к тому, чтобы спеки можно было на ~~90% > > писать автоматически. > > Viy@ давно разработал и предлагает неплохие инструменты > автоматизации, но его идеи раз за разом отвергают. У меня сложилось впечатление, что основные причины недоверия — высокий порог входа в эти инструменты других мейнтейнеров и непонятная выпускающим менеджерам репозитория цепочка ответственности за разломы этого репозитория. По тем или иным причинам их не встраивают в рекомендуемый workflow, например, новичка в ALT Linux Team; новички о них не знают, а матёрым мейнтейнерам надо ехать, а не автомобиль проектировать. > Чем данная > ситуация отличаются? У нас большая часть разработчиков считает, что > писать спеки нужно вручную. И в случае со сложными, нетривиальными > пакетами они правы. Но если и CPAN и т.п., где подход viy@ куда > более практичен. > > > Остаётся только одно соображение в защиту имени BUILD: при ручном > > вмешательстве человека с клавиатурой в хешерницу с результатом > > почему-либо упавшей сборки %_target_platform (или первые 1-2 символа и > > tab-complete) придётся набирать руками. С этой точки зрения значение по > > умолчанию "build-%_target_platform" или даже "build" было бы лучше, а > > "BUILD" — хуже этих двух, потому что shift надо нажимать и коллизия с > > /usr/src/RPM/BUILD. > > > > Вот я и остановился перед выбором из четырёх: > > %_target_platform, build-%_target_platform, build, build-%name-%EVR и > > выбрал первое. Но я на своём варианте не настаиваю, и об этом умолчании > > можно договориться и поменять в сизифе в любой момент обозримого > > будущего, не сломав ни один спек. > > > > Так оказалось, что %_target_platform довольно удобен: > > конкретно %_target_platform уже используется у нас в макросах для meson, > > например; никто не жаловался на возникающие сбои. Да и при чтении лога > > семейство архитектур лишний раз бросается в глаза. В самих спеках > > %_target_platform явно употребляться не будет, коллизия по имени с уже > > существующими файлами маловероятна. > > > > Константным выражением, на которое можно положиться в спеке, выступает > > %_cmake__builddir; многие исправленные спеки в обсуждаемом сборочном > > задании явно используют этот макрос там, где cmake --install не хватает > > и надо руками залезть. > > По-моему, ты перемудрил: решая несуществующую проблему с именем > BUILD по-умолчанию и теоретически (и только!) возможной коллизии, > ты создал очень даже практическую проблему лишнего уровня > абстракции и реальной поломки сотен пакетов. Откуда же там сотни? specs% git grep '%cmake_build [A-Z_a-z]' | wc 45 96 2162 Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.