Re: [devel] [sisyphus -> devel] Стабильный Сизиф

["Alexey I. Froloff" <raorn@immo.ru>]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

* Alexey Tourbin <at@> [060619 17:03]:
> Так можно ли автоматически бороться с анметами (то есть существует ли
> более тонкий автоматический критерий, чем просто давать reject пакетам,
> которые увеличивают количество анметов)?
Ну вот такая идея мне в голову пришла:

Если пакет baz зависит от пакета libfoo, получаемого из исходного
пакета foobar, то пакет baz должен иметь сборочную зависимость на
пакет bar, тоже получаемый из исходного пакета foobar.  Примем
это за постулат.

((note: под это правило не попадают зависимости проставленные
вручную, зависимости на исполняемые файлы (/bin/ls -> coreutils)
и зависимости на модули (python, tcl, но попадает perl). ))

Пакет foobar, генерирующий libfoo у которого сменился SONAME
попадает в отстойник с именем FUBAR.  Далее мы имеем список
FUBAR-src с именами всех исходных пакетов и FUBAR-req-src с
именами исходных пакетов, предоставляющих сборочные зависимости
для FUBAR-src.

Для каждого нового пакета генерим список типа FUBAR-req-src и
если он пересекается с FUBAR-src, то помещаем этот пакет в
отстойник FUBAR.

Если этот новый пакет попадает в список FUBAR-req-src, то
обработка этого пакета блокируется до окончания обработки
отстойника.

Если ни то ни другое, пакет обрабатывается как обычно.


Что я в этой схеме не предусмотрел?  Например когда foo зависит
от libbar и libbaz, находящихся в разных отстойниках.  Есть
реальные примеры таких сочетаний пакетов?  Не раскрыто понятие
"как обычно".

Под "неувеличением количества unmet'ов" наверно лучше следует
понимать "недобавление новых unmet'ов", т.е. схема -2+1 под это
не попадает.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]