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 — это файл или используетс апстримом для иных
нужд, но на практике такое вряд ли встречается).

> В долгосрочной перспективе нам уместно
> (медленно, но верно) стремиться к тому, чтобы спеки можно было на ~~90%
> писать автоматически.

Viy@ давно разработал и предлагает неплохие инструменты
автоматизации, но его идеи раз за разом отвергают. Чем данная
ситуация отличаются? У нас большая часть разработчиков считает, что
писать спеки нужно вручную. И в случае со сложными, нетривиальными
пакетами они правы. Но если и 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 по-умолчанию и теоретически (и только!) возможной коллизии,
ты создал очень даже практическую проблему лишнего уровня
абстракции и реальной поломки сотен пакетов.

Best regards,
Andrew Savchenko