[devel] Re: зависимость наperl(MD5.pm)

[Victor Forsyuk]

Прошу прощения за пропадания. Я понимаю, что участвовать
в разговоре читая рассылку настолько нерегулярно не есть
хорошо, но увы - временами свободное время стремится к
нулю. :(

On Thu, May 22, 2003 at 08:06:07PM +0300, Michael Shigorin wrote:
> On Thu, May 22, 2003 at 07:56:12PM +0300, Victor Forsyuk wrote:
> > Да, я осознаю, что в настоящее время апгрейд setup - это
> > достаточно напильниковая работа. Но это значит, что следует
> > довести до ума этот момент. А вовсе не извращаться в других
> > местах, лишь бы не трогать "достаточно важный" пакет.
> 
> С другой стороны -- "а что в Debian?" -- никто не смотрел?

С третьей ;) стороны - так ли уж важно по сути, как именно это
в Debian? Мы должны правильно строить собственный дистрибутив,
опираясь на логику и целесообразность, а не потому только, что
так сделано в Debian, RHL или, скажем, Owl.

Хотя, можно говорить о Debian в этом плане как о дистрибутиве,
известном (и даже знаменитом) своей строгой packaging policy
и наибольшей беспроблемностью в плане обновлений.

Как бы то ни было, я поискал на packages.debian.org (установленного
Debian у меня нет) /etc/passwd и /etc/group и ничего не нашёл.
Если я правильно понял их поисковую форму, это говорит о том,
что ни один из дебиановских пакетов не содержит их в списке
своих файлов.

Рискую быть занудным, но повторюсь, что никакого смысла включать
эти файлы в %files не вижу. Иными, кроме как %config(noreplace)
они быть не могут. Иметь обновления системных uid/gid в виде
болтающихся .rpmnew - это не решение проблемы обновления, а
головная боль для администратора.

Решение - программное обновление данных системных файлов. И при
этом нет необходимости включать их в список файлов пакета.
Вот только Дмитрий почему-то предлагает делать это в
инсталляционных скриптах пакетов (useradd/groupadd), а я
искренне недоумеваю, что мешает делать это в setup.

Простой пример, почему оставлять заведение пользователей и групп
"на потом" есть плохо и потенциальный источник проблем.
Наличие в дистрибутиве _изначально_ пользователя... ну возьмём для
примера "exim" не даёт мне возможности создать такого пользователя
как обычного (не системного) пользователя (кстати, пример вполне
жизненный - слово exim это ещё и популярное сокращение от
EXport IMport :). Создание его только в инсталляционных скриптах
пакета может привести к конфликту пользователей.

Резюмирую - я просто не вижу смысла откладывать заведение групп
и пользователей до момента инсталляции соответствующих пакетов.
Вопрос не в том, что это _можно_ делать, вопрос в том, что это
ничем не оправдано.