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

["Vladimir D. Seleznev" <vseleznv@altlinux.org>]

On Mon, Sep 03, 2018 at 11:48:04AM +0300, Alexey Tourbin wrote:
> 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?  Куда он направлялся своим
> сборщиком, и где его жизненное предназначение?  Телеология на марше.

Согласен с manowar@, это информация не о предназначении пакета, а о его
происхождении. Она ровном счётом ни на что не влияет, равно как и,
например, buildhost. Назначение этого тега информационное.

> Представьте на секунду, что есть дистрибутив, который состоит из
> "голых" пакетов %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" - это хороший признак работоспособности пакета в новом
> окружении.

Мысль интересная, но далеко не у всех пакетов есть тесты, и не все тесты
обладают достаточным покрытием. Наверное, можно генерировать
какие-нибудь %name-checkpackage, в которые записывать скрипт с
содержимым секции %check, и выделить для них отдельную компоненту. Но
сходу непонятно, когда надо запускать эти скрипты. После сборки каждого
пакета — слишком дорого. Можно периодически на текущем состоянии
репозиториев.

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

А о каком именно наследии вы говорите?

-- 
   С уважением,
   Владимир Селезнев