On Mon, 31 May 2021 16:52:20 +0300 Arseny Maslennikov wrote:
> 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%. :)

И 2 пакета, это повод ломать более сотни? По-моему, проще и
правильнее решить проблему в этой паре пакетов и для остальных
оставить как есть.
 
> Например, в проектах на google c++-стеке встречаются сборочные скрипты
> для Bazel, точка входа в которые называется именно BUILD.
> 
> В одном пакете я даже видел ln -s build BUILD.
[...] 
> > По-моему, ты перемудрил: решая несуществующую проблему с именем
> > BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
> > ты создал очень даже практическую проблему лишнего уровня
> > абстракции и реальной поломки сотен пакетов.
> 
> Откуда же там сотни?
> specs% git grep '%cmake_build [A-Z_a-z]' | wc  
>      45      96    2162
> Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.

Откуда циферки?

$ git grep %cmake_build | wc -l
446

Потенциально сломаны они все.

Best regards,
Andrew Savchenko