[devel] invalid PAM_NAME_SUFFIX - это что?

Alexander Bokovoy =?iso-8859-1?q?a=2Ebokovoy_=CE=C1_sam-solutions=2Enet?=
Пн Ноя 24 00:39:54 MSK 2003


On Mon, Nov 24, 2003 at 12:27:36AM +0300, Dmitry V. Levin wrote:
> > > Можно, конечно, заменить фразу
> > > invalid PAM_NAME_SUFFIX=%{_pam_name_suffix}
> > > на что-нибудь вроде
> > > invalid PAM_NAME_SUFFIX: build system provides no valid pam-devel package
> > > но это, по-моему, ничего не изменит.
> > Изменит. Между прочим, существенно -- правильная диагностика также важна,
> > как и осмысленное закручивание гаек. Чего стоило сразу написать правильную
> > формулировку, тем более, что это уже не первый случай "битвы" за
> > корректные сообщения об ошибках?
> 
> Что мешало вам сообщить раньше, что нынешняя формулировка не вполне
> понятна?  Я понял это менее часа назад.
Мне лично -- отсутствие времени в последние два месяца. Увы. Оно появится,
более или менее, после 4-5 декабря.

Вообще, для разработчика, вводящего новые категории сообщений об ошибках
должно действовать правило -- сообщение об ошибки должно описывать то, что
разработчик думает о возникшей проблеме, а не ее краткое техническое
изложение в терминах грамматики, нарушение которой и вызвало ошибку.
Практика показывает, что это правило реально позволяет уменьшить
вероятность непонимания пользователем разработчика приблизительно в трех
четвертях случаев -- это *очень* много.

> > В частности, о введении в действие проверки PAM_NAME_SUFFIX сообщается
> > только в ChangeLog пакета rpm двумя строчками, не объясняющими ничего по
> > факту проверки. Информация о том, что это такое, отсутствует и в
> > README.ALT этого пакета. В списке devel@ есть косвенное упоминание о 
> > *результатах* действия политики -- в твоем письме от 22 сентября 
> > "I: new unmets in Sisyphus 20030922" -- ни обсуждения, ни объяснения. И
> > далее (23-го) -- запрет на допуск пакетов с нарушением политики в Сизиф.
> > 
> > Более того, файл PAM-Policy.ALT из libpam (обоих) не содержит упоминания о
> > введенной в действие политике. Спрашивается: чем необходимо
> > руководствоваться сборщикам? Хорошо, можно банальным образом поковыряться
> > в скриптах в rpm-build и понять, почему же так все происходит, но надо ли
> > это делать всем? 
> 
> Я не знаю, что тут документировать.
Хотя бы вот это: принципиальная возможность сборки с разными библиотеками-поставщиками
подсистемы PAM требует от любого пакета, использующего функционал PAM, в
том числе и опосредованно (через consolehelper и просто конфигурационные
файлы в /etc/pam.d), вносить pam-devel в список обязательных
BuildRequires.

Это нормально по смыслу?

> По-моему, если пакет для сборки использует libpam-devel, явно (-lpam) или
> неявно (/etc/pam.d/), то в сборочных зависимостях это должно
> присутствовать.  Так было всегда, меняются только конкретные потребности
> (раньше rpmbuild иногда справлялся и без libpam-devel).
> 
> Если ты, Саша, знаешь, что тут следует документировать, то patches are
> welcome.
Для начала, пожалуйста, внеси указанный комментарий, если он тебя
устраивает по смыслу, в PAM-Policy.ALT, а также добавь описание новых
макросов, относящихся к PAM в README.ALT в rpm. Продублировав указанный
комментарий там же -- и в pam.prov/pam.req в виде внятного сообщения об
ошибке, вроде предложенного тобой на замену.

Думаю, что это не требует специальных патчей.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/



Подробная информация о списке рассылки Devel