Re: [devel] [SCM] packages/mdadm: tags/4.0-alt2

["Alexey V. Vissarionov" <gremlin@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 3953 bytes --]

On 2017-11-03 03:51:54 +0300, Dmitry V. Levin wrote:

 >>> split to subpackages to avoid parasitic dependencies;
 >> Заменяем паразитные зависимости на паразитные пакеты?
 >> С какими зависимостями боремся-то?

Прошлый ответ был off-list, поэтому продублирую здесь.
В данном случае было желание отвязаться от udev и systemd.

 >> У mdadm и так зависимостей мало.

Да понятно, что самому ему кроме glibc ничего не нужно...

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

Ну, давай разберем...

 >> Ну какие там various tools? init script и cron script.
 >> Зачем отдельный пакет?

Основная идея была в том, чтобы можно было обойтись установкой
%_sbindir/%name и %_man8dir/%name.8

Ну, еще этот пакет может быть и владельцем конфига - который,
впрочем, полностью опционален.

 > Какие файлы были перенесены в этот mdadm-tools?
 > /etc/cron.d/mdadm /etc/rc.d/init.d/mdadm /etc/sysconfig/mdadm
 > /usr/share/mdadm /usr/share/mdadm/checkarray
 > Какие зависимости переехали вслед за файлами?
 > - coreutils - grep - schedutils - service - vixie-cron
 >
 > Кто пострадал бы из-за этого переезда, если бы он случился? -
 > все, у кого обновится пакет mdadm, например, в результате
 > dist-upgrade, молча потеряют содержимое mdadm-tools со всей
 > функциональностью;

Не критично, но соглашусь с тем, что это может быть неприятно.

 >>> +%package udev
 >> Зачем отдельный пакет? Кому могла помешать зависимость на
 >> udev-rules?
 > Какие файлы были перенесены в этот mdadm-udev?
 > /lib/udev/rules.d/63-md-raid-arrays.rules
 > /lib/udev/rules.d/64-md-raid-assembly.rules
 > Какие зависимости переехали вслед за файлами? - только
 > udev-rules - пакет размером 25 килобайт, у которого нет
 > зависимостей на другие пакеты.

Тем не менее, без этого пакета можно обойтись.

 > даже если представить себе гипотетическую операционную систему

По-моему тут вырисовывается вполне обычная серверная система...

 > с монолитным ядром

Вообще-то Linux и есть монолитное ядро - в отличие, соответственно,
от микроядерных систем. Да, оно может быть модульным, но останется
монолитным :-)

 > без udev

CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

Я, конечно, допускаю, что этой функциональности в каких-то совсем
экзотических случаях может оказаться недостаточно, но это не повод
использовать костыль в userspace вообще всегда. То есть, грамотно
сделанной Linux-системе, пребывающей в добром здравии, костыли не
нужны.

Ну и каждый лишний процесс в userspace - потенциальная дыра.

 > и прочих достижений цивилизации,

Достижения цивилизации бывают очень разными - в том числе и такими,
без которых ты и сам предпочтешь обойтись (например, тяжелая наркота).

 > экономия нескольких десятков килобайт

Лишь бы эти килобайты при очередном обновлении не притащили пачку
зависимостей на сотни мегабайтов...

 > Суммируя всё вышесказанное, следствием обсуждаемого
 > расчленения пакета mdadm стали бы существенные неприятности
 > почти везде, где он сейчас используется, без какого-либо
 > выигрыша, ради которого стоило бы затевать что-либо подобное.

Насколько я вижу, реальная коряква получилась всего одна: нужно
было сделать %name зависящим от всех подпакетов, чтобы ничего
не поломалось даже у слоупоков, которые в 21 веке не знают про
CONFIG_MD_AUTODETECT=y и тип раздела 0xFD - в этом случае они
получат тот же набор файлов. А на хоть немного более продуманных
конфигурациях появится возможность ставить только %_sbindir/%name
и %_man8dir/%name.8 (причем исключительно на случай --grow, ибо
--assemble как минимум лично я запускаю только когда занимаюсь
восстановлением данных - во всех остальных случаях достаточно
просто не мешать ядру работать).


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

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]