Re: [devel] subrepository for 32-bit

[Alexey Gladkov <legion@altlinux.ru>]

On Sat, Jan 29, 2022 at 08:41:21PM +0300, Anton Farygin wrote:
> On 29.01.2022 19:00, Dmitry V. Levin wrote:
> > On Sat, Jan 29, 2022 at 07:38:55PM +0400, Alexey Sheplyakov wrote:
> > > On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> > > > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > > > [...]
> > > > > PI же не про производительность, с другой стороны, особой пользы на
> > > > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > > > выключить PI для них.
> > > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > А давайте немного легче с квантором общности. Возможно, лично Вам пользы от 32-битных
> > > архитектур и нет (хотя мне кажется, что есть, просто Вы её не замечаете).
> > > 
> > > А так-то есть вагон и маленькая тележка armv7 процессоров (и из них собирают
> > > не только одноплатники), и в ближайшие 5 -- 10 лет они никуда не исчезнут
> > > (а потом, возможно, из вытеснит riscv, тоже 32-битный).
> > Интересно, как вы оцениваете множество задач, которые реально решать на
> > таких системах, и множество пакетов в репозитории, которые для этого
> > понадобятся.
> > 
> > Вопрос же не в том, будут ли эмбеддить armv7 и riscv32, а в том, может
> > ли быть для этого полезен Сизиф, и если да, то в какой форме и объёме.
> > 
> > Если нужен только cross toolchain и кастомное ядро, то это один ответ.
> > А если нужен chromium, firefox, kde, и ещё 17+ тысяч исходных пакетов,
> > то это совсем другой ответ.
> 
> Кстати было бы неплохо предусмотреть такой white list - что по умолчанию
> собирать на какой-то архитектуре, а что нет.
> 
> Но его сопровождение может стать отдельной весьма существенной задачей, если
> сразу не придумать её автоматизацию.
> 
> Т.е. - автоматически на сборочнице определять, нужно собирать пакет на 32-х
> битных архитектурах или нет исходя, например, из сборочных чрутов пакетов,
> входящих в whitelist.

На самом деле вопрос стоит ставить шире. Мы тут обсуждаем устаревание и
последующее выкидывание какой-либо архитектуры. Для любой архитектуры икс
будут оставаться пользователи, которые будут против остановки
сопровождения архитектуры икс.

Нужно иметь какой-то протокол, как определить, что затраты на
сопровождение архитектуры выше от плюсов присутствия сизифа на ней.

Возможно, в сборочнице стоит иметь градации поддержки архитектур (я
придумываю на ходу). Для некоторых архитектур можно собирать лишь то что
входит в базой чрут перед их смертью. Когда через ExcludeArch даже чрут не
может быть собран, то выкидывать окончательно. (Это просто абстрактные
мысли на тему).

-- 
Rgrds, legion