[devel] в защиту __cargo

Ср Окт 28 15:11:03 MSK 2026

On Tue, Dec 06, 2005 at 07:52:44PM +0300, Dmitry V. Levin wrote:
> > > Почему?  Одно другого не исключает.  Чрезмерное
> > > употребление макросов снижает читабельность spec-файлов.
> > Тогда было бы неплохо увидеть более официальное обоснование
> > существования %__mv и компании, чем догадки. :)
> %__mv и компания -- это внутренняя кухня rpmbuild, используется
> для запуска mv и компании внутри rpmbuild.
Это утверждение истинно.
Но ведь rpmbuild в тех местах, где он в коде на Си подставляет фрагменты
шелльного текста, мог бы тоже вызывать `mv` словом, без слоя косвенности.
Зачем-то при разработке rpmbuild вставить _такой_ шарнир (i. e. слой косвенности)
понадобилось. Зачем? Полагаю, что чёткий ответ на этот вопрос нам всем
поможет договориться и прочертить границу между чрезмерным и уместным.

Уточню свою мысль.
Например, в пресловутых участках кода rpmbuild можно было бы фрагменты
целиком (или их контекстно малозависимые части) макрообозвать и вытащить
в macros.in. Но почему-то авторы обернули именно пачку утилит. Видимо,
в таких обёртках есть ценность за пределами участков кода rpmbuild.

> Появление этих
> макросов в spec-файлах, видимо, и есть злоупотребление
> макросами.
В спеках явно обращаться к этим __ (т. е. предусматривать перегрузку)
действительно нужно нечасто.
А вот в сложных макрообёртках вроде %cmake, %configure это полезно, и
торчащих зубов __ в спеке не будет.

Если возражение против %__mv было связано только с тем, что у
человеческого читателя спеков дёргается глаз, то избавиться от этого
можно кучей способов, среди которых %define mv __mv, или же просто
забить и писать в спеке по имени. (Там в PATH есть каталог для
обёрток, он стоит первым. Тот, кто желает разок собрать пакет так, чтобы
в окружении были обёртки, может добавить ещё и нагенерить туда обёрток от души.)

On Wed Oct 28, 2026 at 1:43 PM MSK, Rx wrote:
> Здраствуйте!
>
> Первая мысль которая приходит в голову при виде чего либо, что 
> начинается с "_" это то, что это часть внутреннего интерфейса которую 
> стоит трогать только если ты работаешь над ней и знаешь за что она 
> отвечает.  На этот счёт даже есть отдельная старенькая статья  2009-ого 
> TypicalPackagingErrors/InternalMacros 
> <https://www.altlinux.org/TypicalPackagingErrors/InternalMacros>.
Ага. Я забыл про эту страницу :)

> Я подозревал что все макросы с префиксами __ это глобальное 
> переопределение утилит, но насколько глобальные? Было бы неплохо 
> зафиксировать данное соглашение статьёй либо же полноценной политикой.
По итогам обсуждения в сообществе буду готов составить.

> 28.10.2026 11:13, Arseny Maslennikov пишет:
>> On Wed, Oct 28, 2026 at 11:08:02AM +0300, Arseny Maslennikov wrote:
>>> On Wed, Oct 28, 2026 at 10:27:54AM +0300, Rx wrote:
>>>>         По результатам пересборки пакетов картина следующая:
>>>>
>>>> Из 432 пакетов упало 29:
>>>> phrog   aris - Пакет использует устаревший макрос %__cargo. Исправление:
>>> Здравствуйте!
>>>
>>> Я хотел бы предложить оставить макрос __cargo.
>> И, наверное,
>>
>>      __rustc %_bindir/rustc
>>
>> тоже нужен, если его вдруг нет.
> Не особо представляю потребителя данного макроса, сейчас единственным 
> таким потребителем является сам rust. Все остальные вызовы rustc это 
> извлечение версии llvm, хостовой архитектуры и прочей информации которую 
> можно вывести в отдельные макросы.

Потребитель номер раз — ядро Linux (нас это коснётся в конце концов).
Потребитель номер два — с недавних пор systemd.
> - Only the core, alloc and libc crates. Rust code is no_std and there
>   are no other crates. The libc crate isn't needed yet, the bindings
>   generated from the tree's own headers cover libc. And like the
>   kernel we don't use alloc either. Its collections abort when memory
>   runs out. systemd_shared has its own Box and Vec instead, which work
>   like the kernel's: everything that allocates returns an error and
>   there's no global allocator.
> - C linkage only. libsystemd-shared and the dlopen machinery stay as
>   they are. A program written in Rust links libsystemd-shared
>   dynamically just like the C programs do and declares its dlopen()
>   dependencies in .note.dlopen. The Rust crates are linked statically
>   into the programs using them.
> 
> So nothing of the Rust standard library ends up in a program or in
> libsystemd-shared. Per HACKING.md the stripped test-cli-rust binary is
> 32 KB with LTO against 20 KB for its C twin.
https://github.com/systemd/systemd/commit/021112961bd64aec54a1f1e6a6c8fda8b732b705

Я не сомневаюсь, что последуют ещё. :)

>>> Эти бла-бла в начале не просто так; такой макрос по (конечно, не очень
>>> явному) соглашению предназначен для того, чтобы можно было передефайнить
>>> все обращения к %_bindir/cargo в генерируемых скриптах.
>>> Аналогично устроены __make, __ninja,
>>> __mv, __cp, __rm, __install, __chmod, __chown,
>>> __tar, __cpio, __gzip, __bzip2, __xz,
>>> и все остальные.
>>>
>>> Оператор может заменить любую из этих утилит на собственную обёртку, на подкоманду в
>>> multi-call binary навроде busybox, на taskset -c, что угодно.
>>>
>>>      rpmbuild --define "__tar /usr/local/bin/busybox tar" "$@"
>>>      rpmbuild --define "__ninja taskset -c $(</sys/devices/cpu_atom/cpus) ninja" "$@"
>>>      rpmbuild --define '__make bear -- make' "$@"
>>>
>>> Примеры, ясное дело, не исчерпывающие. :)
>>>
>>> Это предусмотренный в подвижной системе дополнительный шарнир:
>>> он нужен не всем и не всегда, но существует.
>> Можно, конечно, оставить оба.
>> "%__cargo" как обозначение "как вызвать программу cargo",
>> "%cargo" как обращение к прагматике cargo.
>>
>> Тогда packager сможет, например, сказать:
>>
>>      rpmbuild --define 'cargo %__cargo auditable' "$@"
>>
>> и у него заработает всё, что сегодня у вас раскрывает "%cargo".
>>
>> В любом случае надо это всё задокументировать, чтобы не пропало.
>
> Если заменить cargo на cargo auditable для всех пакетов и оставить 
> возможность отката на "оригинальный" cargo, то возможно в таком случае 
> есть смысл сохранить макрос, но как будто бы "%define cargo cargo" будет 
> более чем достаточно.

OK, так тоже можно, убедили.
По этому вопросу я амбивалентен; интеллектуальный оператор и так и
так справится, а детерминированную программу, наверное, можно и
подхакать всегда.
Видимо, надо дойти до результата обсуждения выше и тогда решить. :)
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 870 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20261028/13098843/attachment.bin>