On Thu, Aug 23, 2007 at 04:12:53PM +0300, Michael Shigorin wrote: > On Thu, Aug 23, 2007 at 04:19:40PM +0400, Alexey Tourbin wrote: > > То что ты предлагаешь я делал 2 года назад. Для каждого > > src.rpm пакета хранится список пакетов билдрута от предыдущей > > его сборки. То есть таблица . > > (На самом деле достаточно хранить только rpm-file-basename, > > потому что отрезанием -version-release-*.rpm получается > > pkg-name). Теперь достаточно "гнепнуть" (join'ом) старые > > списки на предмет совпадения pkg-name относительно прибывших > > пакетов. Это не только не решает Provides+Obsolets, это не > > решает даже виртуальных зависимостей. > > Хорошо, а инвалидировать такой кэш на основании сравнения > выдранных из пакета BR? Список BR оптимизируется, в этом есть свой смысл. То есть то, реализовано в /usr/share/buildreqs/optimize_package_list является не просто оптимизацией, но и "кристализующей" оптимизацией, проясняющей "смысл понятия". Например, библиотека lib1 может быть собрана сначала с backend1, а позднее пересобрана с backend1. Отсутствие backend1|backend2 в BR при наличии lib1 является БЛАГОМ. К сожалению, в каких-то эзотерических терминах объяснение получается. :) > > Например пришёл пакет libstdc++4.2-devel. Его в предыдущих > > списках нигде нет. Значит, наша система "не догадается" > > пересобрать приплюснутые пакеты. Такое простое опровержение > > Согласен; хотя на такие варианты можно попробовать тоже найти > эвристику подешевле, чем --print-uris -- например, > ^([a-zA-Z_+-]+)[0-9]+(\.[0-9]+)-devel или около того сводится > к более общей сущности \1-devel, которая и проверяется на наличие > в BR (или по /etc/buildreqs/packages/substitute.d/ -- хотя для > новой сборки записи ещё нет). > > Я к тому, что если решение задачи "в лоб" оказывается слишком > дорогим, может иметь смысл разбавить решаемую задачу до > "в большинстве практических случаев". Это не только тестирование для практических случаев. У меня есть идея, боюсь что я сейчас не смогу ее четко сформулировать без привлечения эзотерики. Смысл идеи в том, что каждый входящий пакет переводит репозиторий из состояния1 в состояние2. Переход является транзакционным, то есть в момент перехода разница между состоянием1 и состоянием2 должна быть четко определена (а сам переход "фиксирует" эту разницу). Состояние, в частности, включает в себя статус пересборки всех пакетов. То, что мы сейчас обсуждаем, это "как подешевле выяснить состояние2 в той его части, которая касается пересобираемости пакетов". То есть это мини-проблема при bottom-up подходе. Но решение ее должно быть надежным, иначе неопределенность будет наслаиваться, и уже ничего нельзя будет утверждать наверняка. Так, при переходе состояниеN->состояние(N+1) может выясниться, что очередной пакет очень много всего сломал, тогда как поломка могла случиться намного раньше, просто наши регулярные выражения дали сбой. Другая часть фиксации состояния -- это, например, изменение количества анметов. В общем, после того, как пакет собрался в хешере, нужно для него вычислить новое состояние, на основе целого ряда проверок, как минимум пересборка и анметы. Если новое состояние не хуже старого, тогда фиксация проходит автоматически. Если же оно является в чем-то хуже старого, тогда требуется подтверждение или retract вручную, со стороны maintainer'а пакета и/или со стороны "ответственного товарища". То что "слишком дорого" это в конечно счете надо смотреть во сколько это выльется по деньгам. Прибедняться тоже не надо, кашу из топора не сваришь, значит нужно обстоятельно прикинуть, чево и сколько хотелось бы иметь. И что это дает. Я считаю что предварительное вычисление состояния2 дает очень много -- по сути это разница между знанием и невежеством, между высокой определенностью и высокой неопределенностью.