[devel] Изменения в сборочнице

[Alexey Tourbin]

2018-09-03 10:00 GMT+03:00 Vladimir D. Seleznev <vseleznv на altlinux.org>:
> On Mon, Sep 03, 2018 at 04:38:22AM +0300, Alexey Tourbin wrote:
>> 2018-08-30 23:42 GMT+03:00 Vladimir D. Seleznev <vseleznv на altlinux.org>:
>> > Доброго времени суток!
>> >
>> > Не раньше завтрашнего вечера в сборочнице произойдут следующие
>> > изменения:
>> >
>> > * будет запрещено копирование пакетов в бранчи;
>> > * будет разрешена пересборка пакетов для Sisyphus без повышения релиза
>> > пакета с помощью команды rebuild.
>>
>> А почему будет запрещено копировать пакеты в бранчи?  Потому что были
>> случаи, что скопированные пакеты не работают?  Но ведь целый класс
>> пакетов, таких как 0ad-data.noarch, иммьюн к особенностям бранчей.
>
> Это правда, но мне видится корректным решением собирать пакеты в родном
> окружении, нежели копировать из чужого бранча. А если такой иммьюнный
> пакет не соберётся, то это явный признак, что что-то идёт не так.

Ну значит некоторые пакеты все же копировать можно, но поскольку мы
наверняка не знаем, какие именно можно, а какие нельзя, то проще
запретить. Этот принцип действия называется "как бы чего не вышло", и
он мне не нравится тем, что отметает все рациональные построения по
части зависимостей как недостаточные. Кстати, и термин "родное
окружение" - он ведь не чисто технический, а с элементом метафоры.
Неохота досконально разбираться, что там происходит в каждом отдельном
случае, какие бывают классы случаев и т.п. Проще окрестить это
неродной средой и вздохнуть с облегчением.

И все же как стратегия минимизации риска запрет копирования имеет
некоторый смысл. Но это крайняя мера, которая проистекает из крайнего
незнания и крайнего риска. Животное когда слышит, что в кустах что-то
шуршит, то оно не знает, притаился ли там лев, или же это просто
ветерок дует.  Но с точки зрения выживания ему гораздо выгоднее
убежать, даже если это всего лишь ветерок (по-научному это называется
risk aversion as an evolutionary adaptation и т.п.).  То есть еще и
цена ошибки сюда примешивается, в духе Pascal's wager. Но более
осмысленное управление рисками появляется только по мере прогресса
знания. А из одного только незнания ничего более умного, кроме как
бежать и запрещать, извлечь нельзя.

>> Ну и знаете, бывали случаи, что и собранные в родной бранч пакеты не
>> работают. (Помню,  во время сборки кончилось место на диске, и у
>> Виталика Кузнецова собралась Самба с утранкейтеным бинариком. В самом
>> конце его зарезал bad_elf_symbols. Но пасаран!)
>>
>> Другими словами, плохие линии аргументации опираются на anecdotal
>> evidence.  Типа, а знаете что бывает?  Один мужик ночью вышел на
>> улицу, а там НЛО прилетело и его забрало.  Поэтому не надо по ночам
>> шастать по улице.
>
> А ещё бывают формально собранные корректно, без внешних вредящих
> факторов, но не работающие по самым разным причинам, которые наши
> проверка не отлавливают, и отловить которые в общем случае невозможно.
> Но эти всё не относится к копированию и не говорят в пользу того, что
> копирование пакетов — хорошая практика.

Надо было систематизировать все случаи неработоспособности пакетов
после копирования. Без этого получается решение, основанное на
незнании.

>> А также мне не нравится идея, чтобы в пакет прибивать гвоздями
>> информацию, для какого бранча он собран.
>
> Чем?

Ох... Ну я ставлю под сомнение "стабильный бранч" как первичное
понятие. Это понятие вторичное, маркетинговое и подражательное Ред
Хату.  А первичное понятие - это пакет coreutils, в нем лежит
программа /bin/cat, которая слинкована с libc.so.6 и т.д.
Спрашивается, к какому бранчу по классификации Линнея этот пакет
относится, к ALT SP 7 или к GOMIX 8?  Куда он направлялся своим
сборщиком, и где его жизненное предназначение?  Телеология на марше.

Представьте на секунду, что есть дистрибутив, который состоит из
"голых" пакетов %name-tar.gz, и устанавливаются они командой (cd / &&
tar xf).  Замнем также некоторые несущественные детали.  В таком
дистрибутиве действительно единственной стратегией является жесткая
сегрегация подходящих и не подходящих под этот дистрибутив пакетов,
поскольку понятия информации о пакете нету, и восстановить
метаинформацию никак нельзя. Надо брать пакеты из правильной папки, в
которой они лежат! А иначе all bets are off.

К понятию "стабильный бранч" есть много других претензий, и я даже не
знаю, стоит ли начинать и ввязываться в этот разговор.  Например, Ред
Хат в мошенническим образом (по нашим понятиям) поставляет в свои
старые дистрибутивы новый тулчейн (он называется devtoolset-7, и
насколько я понял, он даже не собирается из исходников, а откуда-то
готовые бинарики копируются).  Потому что дистрибутив со старым
тулчейном быстро девальвируется по объективным рыночным к нему
ожиданиям. Андрей Черепанов в телеграме кажется жаловался, что новый
софт часто не удается собрать в старые бранчи из-за старого
компилятора, прямо хоть новый gcc.tar.gz в firefox.src.rpm
заворачивай. Так. А тогда собственно возникает вопрос о ценности
бранча. В чем вообще ценность этого вашего стабильного дистрибутива
состоит, если в нем gcc.tar.gz нужно всегда иметь под рукой? Вопрос
этот я боюсь в конечном счете не технический.

>> Надо было протоколировать все неочевидные случаи нарушения
>> работоспособности после копирования и докапываться до причины, что там
>> произошло, и дальше думать, как вынести релевантную информацию в
>> зависимость у пакета.  Надо делать зависимости более достаточными в
>> плане описания работоспособности, а не искусственно сегрегировать
>> пакеты по предначертанному признаку.
>
> Если бы это было возможно в общем случае. Вы способны формализовать, что
> такое работоспособный пакет?

Ну вот есть какая идея. При сборке пакета же выполняется "make test".
Надо научиться так перепаковывать этот "make test", чтобы он мог
выполняться в любой момент супротив установленного пакета в
хост-системе, а не токмо в дереве сборки. Тогда работоспособность
"make test" - это хороший признак работоспособности пакета в новом
окружении.

Но конечно это нельзя всё поставить на поток к завтрашнему дню.
Наследие sourсe-based дистрибутивов тянет нас назад, и еще очень долго
будет тянуть.