[devel] rpm: некорректные макросы

[Victor Wagner]

В Fri, 13 Dec 2019 21:18:43 +0300
Andrey Savchenko <bircoph на altlinux.org> пишет:


> > > $ rpm -q rpm
> > > rpm-4.13.0.1-alt15.x86_64
> > > $ rpm --showrc | grep "@.*@"
> > >         %{expand:%(cat /usr/lib/rpm/macros.d/*.env
> > > @SYSCONFIGDIR@/macros.d/*.env 2>/dev/null)} -14: __install_info
> > > @__INSTALL_INFO@ -14: __lzma     @__LZMA@ -14: __pgp      @PGPBIN@
> > > -14: __subst    @__SUBST@
> > > -14: _build_arch        @RPMCANONARCH@
> > > 
> > > Что мы будем с этим делать? На мой взгляд нужно или задать
> > > значения, или убрать эти макросы вовсе.  
> > 
> > Из процитированного видно, что это всё было скопировано из
> > rpm-build, в самом rpm не используется, а rpm-build продолжает
> > использовать свои определения.  
> 
> Прорезюмирую результат обсуждения IRL: значения этих и многих
> других макросов нужно брать из rpmbuild. Из rpm их лучше в
> дальнейшем удалить во избежание недоразумений.

Тут есть одна тонкость - нету у юзера на production сервере
rpmbuild. И не должно быть. Ибо средства разработки это толстенная дыра
в безопасности.

А у меня проблема возникла именно из задачи  - "прописать юзеру в
/etc/apt/sources.list.d правильный репозиторий, не полагаясь на то,
что юзер знает, какая у него архитектура и версия платформы".

Поэтому нужен способ точно определить архитектуру установленной системы.
Именно системы, а не ядра, так как никто не обещал в нашу эпоху
контейнеров, что они совпадают.
Правда, видимо, лучше это делать не посредством rpm, поскольку вызов rpm
изнутри %post скрипта вообще говоря недопустим.

Либо тогда надо передеелывать логкику работы apt, чтобы там, как и в
Debian, не требовалось явно указывать архитектуру в URL-ках.

Вот у yum или zypper, например я могу в url-ке на репозиторийй написать
$releasever и $basearch и он мне сам подставит то, что надо.





-- 
                                   Victor Wagner <vitus на wagner.pp.ru>