[devel] Излишние авто зависимости?

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2023-08-04 23:34:29 +0300, Alexey Shabalin wrote:

 > Благодаря /usr/lib/rpm/0common-files.req.list у нас появляются
 > различные зависимости в пакетах. Например, благодаря такой
 > строчке: /etc/logrotate.d logrotate если пакет содержит что-то в
 > /etc/logrotate.d/* то так же будет установлен и пакет logrotate.

Увы, проблема нетехническая: многие мейнтейнеры просто не хотят об
этом думать.

 > Хотел бы поднять пару вопросов о содержимом 0common-files.req.list
 > и возможно пересмотре его. 1) Когда для подсистемы используется
 > одна единственная реализация, например alternatives или chrooted,
 > то проблем нет. А вот если в репозитории присутствует несколько
 > реализаций какой либо подсистемы, то будет прилетать и ненужная
 > тоже. Если я добавил systemd unit файл, это не означает
 > что должна появится зависимость на systemd, т.к. возможно
 > используется sysv.

Именно так. Я в соседней ветке только что написал, что это лечится
%package hier
и
%files hier
%dir ...

То есть, если какой-нибудь systemd-hier создаст мне /lib/systemd,
а какие-то другие пакеты насвинячат туда бесполезными текстовыми
файлами - ну и пусть с ними, они занимают в пределах мегабайта.

 > Как пример
 > /etc/X11/xinit.d xinitrc (все равно не работает под wayland)

Напрашивается xinitrc-hier или даже xorg-hier

 > /etc/cron.d vixie-cron (я использую systemd timer, как мне
 > удалить vixie-cron? а если вместо умершего vixie-cron приедет
 > новая реализация?)

Аналогичный пакет cron-hier

 > /etc/rc.d/init.d service (зачем мне service на systemd? на
 > systemctl нельзя делать зависимости, а на service можно?)

sysvinit-hier

Насколько я понимаю, на способность systemd найти и выполнить
скрипт sysvinit это никак не влияет.

 > /etc/xinetd.d xinetd (я давно ничего не запускаю через xinetd,
 > как мне его удалить? в systemd есть этот функционал)

А xinetd вообще не нужен. Нигде, никому и ни для чего. Вот уже
скоро 20 лет тому как.

 > 2) второй вопрос, а должны ли конфигурационные файлы или
 > доп.скрипты порождать зависимость на эти подсистемы.

Разумеется, нет.

 > Пусть установится конфиг и лежит себе, никого не требуя.

В норме - именно так. От каталога, не принадлежащего ни одному
пакету, может пострадать только чей-то перфекционизм.

 > /etc/xinetd.d xinetd (даже если есть конфиг для xinetd, я давно
 > ничего не запускаю через xinetd, как мне его удалить?)

%package hier

 > /etc/sudoers.d sudo (да мало ли зачем в пакет упаковали настройки
 > sudo, не буду я использовать sudo, хочу удалить)

%package hier

 > /etc/ppp/ip-up.d ppp-common Вот я хочу на сервере удалить все
 > про ppp, он мне не нужен, у меня ethernet соединение и ничего
 > больше не предвидится. Но оказывается в пакете sendmail-common
 > есть скрипт /etc/ppp/ip-up.d/sendmail. А удалить sendmail-common
 > я не могу, он мне нужен для postfix.

Вынести его в какой-нибудь sendmail-ppp. Или вообще удалить, ибо
dialup, хвала Щеголеву, сдох почти 15 лет назад.

 > /etc/emacs/site-start.d emacs-base rpm -e emacs-base ошибка:
 > Неудовлетворенные зависимости: /etc/emacs/site-start.d нужен для
 > (установлен) gettext-tools-0.21-alt1.x86_64 Да мало ли что в
 > пакет запихнули конфиг для emacs, зачем мне emacs устанавливать?

Конфиг выкинуть. Если не совсем, то в отдельный пакет.

 > Да, я знаю что emacs-base почти пустой пакет, но и в таком виде
 > он мне тоже не нужен.

+100500

 > Может ли кто-то из core team (rpm-build: @core imz at vt)
 > провести ревизию содержимого /usr/lib/rpm/0common-files.req.list
 > и привести его к современным реалиям? Я не буду спорить,
 > возможно какие-то подсистемы лучше не трогать (например sudo),
 > но некоторые уже лишние?

Беда в том, что у большинства коллег, которые принимают такие
решения в своем узком кругу, нет опыта эксплуатации статистически
значимого количества систем в статистически значимом количестве
мест, что вынуждает уже всех разработчиков тащить поддержку кучи
ээээ... антиквариата.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net