From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=altlinux.org; s=dkim; h=Subject:In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:To:From:Date:Sender:Reply-To: Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=bypAYL2sZXgG13rjK1eObcsiCyI6QjROuOb3m1WeW5M=; b=dXU/FRE3U7vInfE3a3tM5uMC/l 0eLFVwEegS/Or269M+9w6vJa49IcHpWgoVvO0eTa4LxnfsYDNcUe/7rKmlvFZGNp7F7W7i1E+WR/5 nb13VAV+BFdj/sikhMm+HSiHKavSGb6acX6n5i6ossjWHRMhRp/zhJcyvr9SLpME+F/H0zVJn7O9d FgHDt0EF+npNoD4ENrhbdjBvXVA2QQYxZ3KRjWUvQwC/vt1/iQ2QGKRGh/Rl7oiyl/h5VciiWpw2Q 7yp06KqHgNHv1xV9CJRNyGZGVPZy0sxRleQuiR0/3DKHivMdu4aMIRVtdlEQhRWGdlpoSxlSTcTpf H6qFRlgw==; Date: Mon, 8 Oct 2018 20:44:24 +0300 From: "Vladimir D. Seleznev" To: ALT Linux Team development discussions Message-ID: <20181008174422.GD26730@portlab> References: <20180830204231.GA15886@localhost.localdomain> <20180903070020.GA22197@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: 185.6.174.98 X-SA-Exim-Mail-From: vseleznv@cs.msu.ru X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail.cs.msu.ru) Subject: Re: [devel] =?utf-8?b?0JjQt9C80LXQvdC10L3QuNGPINCyINGB0LHQvtGA0L4=?= =?utf-8?b?0YfQvdC40YbQtQ==?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 17:44:28 -0000 Archived-At: List-Archive: List-Post: On Mon, Sep 03, 2018 at 11:48:04AM +0300, Alexey Tourbin wrote: > 2018-09-03 10:00 GMT+03:00 Vladimir D. Seleznev : > > On Mon, Sep 03, 2018 at 04:38:22AM +0300, Alexey Tourbin wrote: > >> 2018-08-30 23:42 GMT+03:00 Vladimir D. Seleznev : > >> > Доброго времени суток! > >> > > >> > Не раньше завтрашнего вечера в сборочнице произойдут следующие > >> > изменения: > >> > > >> > * будет запрещено копирование пакетов в бранчи; > >> > * будет разрешена пересборка пакетов для 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 дистрибутивов тянет нас назад, и еще очень долго > будет тянуть. А о каком именно наследии вы говорите? -- С уважением, Владимир Селезнев