[devel] other specs with "if 64"; was: Re: [AArch64] python3 spec fix

[Alexey Shabalin]

27 мая 2016 г., 21:24 пользователь Ivan Zakharyaschev
<imz на altlinux.org> написал:
>
> On Fri, 27 May 2016, Alexey Tourbin wrote:
>
>> 2016-05-27 11:18 GMT+03:00 Ivan Zakharyaschev <imz на altlinux.org>:
>>>
>>> Я-то не знаю, какой в каких спеках оно может иметь смысл, поэтому начал
>>> это
>>> обсуждение. (Хотел выкатить сразу большой список примеров, но пока так.)
>>
>>
>> Смысл 64-битной платформы. Имхо на 64-битность стоит смотреть не через
>> интерфейс large files, а через интерфейс mmap. Если можно очень
>> большой файл отобразить в память, то платформа 64-битная. То есть
>> играет роль адресное пространство и размер указателя. Но на всех
>> платформах имеем: sizeof(void*) == sizeof(long). Так что за неимением
>> лучшего надо проверять LONG_BIT.
>>
>> А что вы хотите исправить в пакетах?
>
>
> Облегчить работу тем, кто будет массово собирать эти пакеты на других
> архитектурах (среди них некоторые 64-битные: aarch64, эльбрус)
>
> Ну "облегчить" значит перейти из ситуации: несколько сотен пакетов не
> собралось (по каким-то глупым причинам, самая простая из которых
> несовпадение %_lib и lib) -- в ситуацию: несколько пакетов, требующих
> особого внимания по хитрым причинам (требуют написания
> архитектурно-зависимого кода), не собралось, а для остальных сработали те же
> приёмы, которые сработали для их сборки для x86_64 или i586.

Вы же сами пишете, что хотите "облегчить" жизнь. Придумывая новые
макросы для rpm вы только усложняете. И нужный макрос уже есть, это
ExclusiveArch. :)

>> 1) Некоторые пакеты настолько беспомощны, что они не хотят свериться с
>> препроцессором, а хотят, чтобы им явно сказали: "у нас 64 бита". Хотя,
>> зачем? Использовали бы просто long и e.g. 1L в арифметике.
>>
>> 2) Некоторые пакеты поддерживают два режима на 64-битной платформе:
>> неупакованный 64-битный и упакованный 32-битный, второй с некоторыми
>> ограничениями на размер задачи и т.п. (CoinCsdp-6.1.1 можно было бы
>> отнести к этому классу, если бы он не был слишком крив в других
>> отношениях). Но как тогда его "исправить"? Он может работать в том или
>> другом режиме.
>>
>> В общем, мне показалось, что вы хотите, чтобы rpm вам дал простой
>> ответ, как исправить кучу кривых пакетов. Да никак их не исправить!
>> Лучше их выкинуть, или хотя бы обновить до последней версии (а не
>> заниматься пересборкой с увеличением релиза).

Полностью поддерживаю. Такой пакет лучше выкинуть, если ни мантейнеру,
ни сборочному роботу он не нужен.


-- 
Alexey Shabalin