Summary: | conflict (foomatic) | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Artem Zolochevskiy <azol> |
Component: | foo2zjs | Assignee: | Michael Shigorin <mike> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P2 | CC: | at, lav, mike, viy |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Artem Zolochevskiy
2007-09-11 18:06:39 MSD
*** 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) список всех файлов во всех пакетах. И перед тем как пропускать в репо проходится по этому списку и материться если есть файловый конфликт, но нет реального. |