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

[Andrey Savchenko]

On Mon, 16 Dec 2019 16:16:20 +0300 Andrey Savchenko wrote:
> On Mon, 16 Dec 2019 03:46:13 +0300 Alexey V. Vissarionov wrote:
> > On 2019-12-15 18:06:45 +0300, Victor Wagner wrote:
> > 
> >  >> Прорезюмирую результат обсуждения IRL: значения этих и многих
> >  >> других макросов нужно брать из rpmbuild. Из rpm их лучше в
> >  >> дальнейшем удалить во избежание недоразумений.
> >  > Тут есть одна тонкость - нету у юзера на production сервере
> >  > rpmbuild. И не должно быть. Ибо средства разработки это
> >  > толстенная дыра в безопасности.
> > 
> > И не нужны они там.
> > 
> >  > А у меня проблема возникла именно из задачи - "прописать юзеру
> >  > в /etc/apt/sources.list.d правильный репозиторий, не полагаясь
> >  > на то, что юзер знает, какая у него архитектура и версия платформы".
> > 
> > В смысле, репу добавить? А откуда в sources.list.d/ новый файл
> > попадет? По уму - из пакета. Но тогда при сборке этого пакета вся
> > необходимая информация уже доступна.
> > 
> >  > Поэтому нужен способ точно определить архитектуру установленной
> >  > системы. Именно системы, а не ядра, так как никто не обещал в
> >  > нашу эпоху контейнеров, что они совпадают.
> > 
> > Дык `uname -m` внутри контейнера вполне говорит i686 - даже когда
> > хост x86_64 (у меня других уже давно нет).
> 
> На e2k не всё так просто. Для совместимости с МЦСТ у нас uname -m
> возвращает e2k на всех поколениях, а человеку нужно разделять v3 и
> v4.
> 
> В скором времени я добавлю поддержку корректного значения %_arch
> в rpm. На других архитектурах сейчас так же, так что есть смысл
> выровнять с ними e2k.

Исправлено в rpm-4.13.0.1-alt15.E2K.1 в sisyphus_e2k и отправлено на
рассмотрение в виде rpm-4.13.0.1-alt16 в основной Сизиф (task
243088).

Best regards,
Andrew Savchenko
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20191216/99654858/attachment.bin>