Eugene Berdnikov -> [email protected] @ Fri, 28 Sep 2012 11:19:24 +0400:
>> >> >> Ну, ты хотя бы эти три раскрой. Вот у тебя пакет, который >> >> >> внутри кода использует имя группы, допустим, remote-dev. Начнем >> >> >> с вопроса "как ты в postinst обнаруживаешь, что то же имя группы >> >> >> с другими целями использует какой-то другой пакет? >> >> >> >> EB> Не в postinst, а в preinst -- по статус-коду от groupadd. >> >> >> >> ... который будет точно таким же, если это ты сам при прошлой установке >> >> ее добавил. >> >> EB> Я немного знаю борновский шелл и потому умею комбинировать разные >> условия >> EB> в предикаты. :-) В данном случае нужно скомбинировать статус от >> groupadd >> EB> с параметром $1, в который dpkg передаёт "install", "upgrade", etc. >> >> Цикл установка-снос-установка эта система либо не переживает, либо >> сносит группу при сносе. Подразумевая, что она ТОЧНО никому больше не >> нужна, и юзеров в нее не добавляют (то есть информацию о членстве в >> группе при сносе сохранять ТОЧНО не надо). EB> Ну да, изначально к рассмотрению была предложена ситуация, когда пакет EB> считает свою группу уникальной, тогда обнаружение группы с идентичным EB> именем при установке означает конфликт. Самая верхняя твоя цитата: EB> "то же имя группы с другими целями использует какой-то другой пакет". Изначально - в смысле Олександром - как раз нет. Он как раз писал (в том числе) о группах потенциально общего пользования. И в моей цитате существенно "с другими целями". Если с теми же целями - то это как раз нормально. Впрочем, даже в случае уникальности, если в группу надо добавлять реальных юзеров, то сносить ее при remove нельзя, можно только при purge. А значит, цикл установка-снос-установка все равно приводит тебя к false positive. Нет, опять же можно делать разделение "есть заполненный конфиг - нет заполненного конфига" для различения ситуации "был remove или не было", но тут ты немедленно станешь недружелюбным по отношению к пресидам debconf. Это тоже можно учесть и обработать, но сложность задачи и количество информации, которую нужно добыть и учесть, растет на глазах. Как раз в случае уникальности при грамотном выборе имени группы можно рассчитывать на то, что наличие ее в системе НЕ является признаком конфликта, а является вот ровно следом от прошлой установки, и надо молча использовать готовое, а не подскакивать нервно. >> При таком предположении >> проще взять заведомо уникальное имя группы, сгенерированное путем >> хэширования вывода /dev/random в момент сборки пакета, и не париться. EB> Хэш плох тем, что имя группы будет длинным и/или лишённым EB> смысловой нагрузки. При этом от софтины требуется возможность EB> менять имя своей рабочей группы. Осмысленный префикс и часть хэша. git вон сокращает в норме до первых 7 символов свой sha1, на практике хватает. (Он, правда, умеет работать и с полным, и возможно, даже каждый раз проверяет на уникальность сокращенный прежде чем выбрать ОДИН коммит - но на коллизию по полному он уже явно не рассчитан. Но это детали, а на практике семи хватает.) exim-d25caac вряд ли так уж сильно уступает в осмысленности Debian-exim и всего на 1 символ длиннее, и при этом шансы нарваться на то, что кто-то другой случайно получит со своего /dev/random такой же результат, куда ближе к нулю, чем вероятность допустить ошибку в решении вышеобсуждаемой задачи. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
