при обновлении получил пачке вот таких: file /usr/share/foomatic/db/source/printer/HP-Color_LaserJet_1600.xml from install of foomatic-db-3.0.2-alt4 conflicts with file from package foo2zjs-20060523-alt0.4
*** This bug has been marked as a duplicate of 12721 ***
Это был INVALID, такие баги надо вешать на более левые пакеты, а не foomatic. Я в курсе и постараюсь исправить ASAP. Если поможешь патчиком -- будет ещё чуть быстрее. Перевешиваю себе.
Пачки, кстати, тоже лучше полностью приводить -- там штуки четыре наложились.
fixed in foo2zjs-20060523-alt0.5
Однако хочу напомнить, что foomatic обязан теперь иметь conflicts с более старой версией этого пакета. Иначе при точечных обновлениях будут файловые конфликты.
Я подумал и вспомнил, что лучше бы такое в foomatic не втягивать. Если втягивает апстрим, то мы почти ничего не можем сделать -- отслеживать все связанные версии более-менее реально, если этим всем занимается один человек. Делающие точечные обновления должны быть в силах, как мне кажется, понять и разрулить конфликты такого плана.
Миша, если некие пакеты конфликтуют по файлам между ними должен быть конфликт. Если этого конфликта нет, то это blocker. Однозначный. В связи с этим раз в foomatic появлись файлы из foo2zjs, то нам надо: а) убрать эти файлы в новых сборках foo2zjs; б) в foomatic поставить конфликт на старые версии foo2zjs; Эх, как не хватает у логики incominger проверки на подобные ошибки. Да, я уверен что данная ситуация это ошибка упаковки foomatic.
не ошибка, а целенаправленная диверсия ;) Вообще это проблема в upstream где никак не могут определиться какие данные хранятся в foomatic, а какие в сопутствующих пакетах. При очередной сборке проверять все возможные пакеты с возможными xml-файлами - теоретически неразрешимая задача.
Вполне разрешивая для incominger скриптов. Если новый пакет содержит в себе файлы, которые есть в других пакетах, и при этом не содержит конфликта на этот пакет -- мы имеем blocker и повод не пропускать пакет, и прислать мантейнеру полный список конфликтных файлов. Далее уже дело мантейнера либо исключить у себя эти файлы, либо поставить конфликт на чужой пакет (возможно с указанием версии), и дальше уже тому мантейнеру придется чтобы сохранить устанавливаемость исключить в следующих сборках эти файлы.
Разве что как некая (comm?) проверка на этапе вот того самого прикарманивания...
comm будет долго. IMHO лучше кэшировать (в sqlite/bdb) список всех файлов во всех пакетах. И перед тем как пропускать в репо проходится по этому списку и материться если есть файловый конфликт, но нет реального.
