[devel] RemovePathPostfixes

Vladimir D. Seleznev vseleznv на altlinux.org
Чт Фев 4 23:12:32 MSK 2021


On Thu, Feb 04, 2021 at 10:45:50PM +0300, Alexey V. Vissarionov wrote:
> On 2021-02-04 20:13:24 +0300, Dmitry V. Levin wrote:
> 
>  >>> Эта "фича" нужна для того, чтобы легко плодить конфликтующих
>  >>> альтернативных провайдеров, что, на мой взгляд, для
>  >>> репозитория вредно.
>  >> Это именно то, чего от репы ждут админы
>  > Обоснуй.
> 
> Никто не любит, когда за них принимают решения, не спросив, что
> именно им нужно. Классический пример - /usr/sbin/sendmail: это
> имя файла уже много лет прибито гвоздями в куче [говно]кода, и
> избавиться от него практически невозможно, хотя само шлимыло уже
> давно сдохло. Предоставить этот файл могут (у нас) пакеты exim,
> msmtp и postfix, причем что именно ставить - решает админ. Более
> того, если настраивать сервер по уму, лучше будет поставить два
> пакета - exim или postfix в качестве демона SMTP (который будет
> слушать *:25) и msmtp (который будет запускаться из-под обычных
> бесправных пользователей как /usr/sbin/sendmail и отправлять
> сообщения через смартхост на ::1).
> 
> Так вот: простейший способ обеспечить необходимую гибкость при
> установке - сделать этот самый /usr/sbin/sendmail симлинком и
> вынести в %package %name-sendmail во всех трех пакетах. А кроме
> того, что простейший - еще и самый понятный админу, который со
> всей этой колбасней работает: "вот тут ставим postfix, который
> будет смартхостом, рядом ставим msmtp и msmtp-sendmail, чтобы
> отправлять почту через этот смартхост; а теперь делаем еще 30
> серверов уже без postfix, а только с msmtp и msmtp-sendmail -
> они будут все слать через первый сервер".

Мне кажется, ты только что изобрёл alternatives.

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

А этот абзац противоречит предыдущему.

-- 
   WBR,
   Vladimir D. Seleznev


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