Hi, On Thu, Nov 02, 2017 at 02:00:12PM +0300, Dmitry V. Levin wrote: > On Thu, Nov 02, 2017 at 09:11:37AM +0000, Alexey V. Vissarionov wrote: > > Update of /people/gremlin/packages/mdadm.git > > > > Changes statistics since common ancestor `270b6b59826e674d04a51912755bb47c991dc139' follows: > > mdadm.spec | 58 ++++++++++++++++++++++++++++++++++++++++++++++++---------- > > 1 file changed, 48 insertions(+), 10 deletions(-) > > > > Changelog since common ancestor `270b6b59826e674d04a51912755bb47c991dc139' follows: > > commit e11470b4cd0ff7cd0548571e359f88dc4ac03f7f > > Author: Gremlin from Kremlin > > Date: Thu Nov 2 11:52:57 2017 +0300 > > > > split to subpackages to avoid parasitic dependencies; > > Заменяем паразитные зависимости на паразитные пакеты? > С какими зависимостями боремся-то? У mdadm и так зависимостей мало. Полагаю, что будет полезно подробно разобрать этот случай как модельный, чтобы не повторять ошибок. > > +%package tools > > +Summary: Various tools and init script for %name > > +Group: System/Configuration/Hardware > > +Requires: %name = %version > > +%description tools > > +%summary > > Ну какие там various tools? init script и cron script. > Зачем отдельный пакет? Какие файлы были перенесены в этот mdadm-tools? $ rpmquery -lp mdadm-tools-4.0-alt2.noarch.rpm /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 со всей функциональностью; - все дистрибутивы точно так же молча потеряют содержимое mdadm-tools, если только их профили не будут адаптированы. Кто потенциально выиграл бы из-за этого переезда, если бы он случился? - те, у кого не установлены пакеты service и/или vixie-cron, могли бы сэкономить несколько сотен килобайт; откуда могли бы взяться такие экзотические пользователи? создатели узкоспециализированных инструментальных чрутов без service и vixie-cron? адепты systemd, избавившиеся от service и vixie-cron? - те, кому по какой-то причине не нужна функциональность checkarray и init.d/mdadm, и кто по какой-то причине хочет их удалить, а не выключить. Что в итоге? Неприятности вследствие переезда серьёзные, выигрыш ничтожный. > > +%package udev > > +Summary: udev rules for %name > > +Group: System/Configuration/Hardware > > +Requires: %name = %version > > +# due to /lib/udev/rules.d/64-md-raid.rules > > +Conflicts: udev < 151 > > +%description udev > > +%summary > > Зачем отдельный пакет? > Кому могла помешать зависимость на udev-rules? Какие файлы были перенесены в этот mdadm-udev? $ rpmquery -lp mdadm-udev-4.0-alt2.noarch.rpm /lib/udev/rules.d/63-md-raid-arrays.rules /lib/udev/rules.d/64-md-raid-assembly.rules Какие зависимости переехали вслед за файлами? - только udev-rules - пакет размером 25 килобайт, у которого нет зависимостей на другие пакеты. Кто пострадал бы из-за этого переезда, если бы он случился? - все, у кого обновится пакет mdadm, например, в результате dist-upgrade, молча потеряют содержимое mdadm-udev со всей функциональностью; - все дистрибутивы точно так же молча потеряют содержимое mdadm-udev, если только их профили не будут адаптированы. Кто потенциально выиграл бы из-за этого переезда, если бы он случился? - никто; даже если представить себе гипотетическую операционную систему с монолитным ядром без udev и прочих достижений цивилизации, экономия нескольких десятков килобайт вследствие отказа от установки /lib/udev/rules.d/* сложно воспринимать как заметный выигрыш. Что в итоге? Неприятности вследствие переезда серьёзные, выигрыша нет. > > +%package systemd > > +Summary: systemd support for %name > > +Group: System/Configuration/Hardware > > +Requires: %name-udev = %version, %name-tools = %version > > +%description systemd > > +%summary > > Почему init script и systemd unit files в разных пакетах? Какие файлы были перенесены в этот mdadm-systemd? $ rpmquery -lp mdadm-systemd-4.0-alt2.noarch.rpm /lib/systemd/system-shutdown/mdadm.shutdown /lib/systemd/system/mdadm-grow-continue@.service /lib/systemd/system/mdadm-last-resort@.service /lib/systemd/system/mdadm-last-resort@.timer /lib/systemd/system/mdadm.service /lib/systemd/system/mdmon@.service /lib/systemd/system/mdmonitor.service Какие зависимости переехали вслед за файлами? - никакие Кто пострадал бы из-за этого переезда, если бы он случился? - все, у кого обновится пакет mdadm, например, в результате dist-upgrade, молча потеряют содержимое mdadm-systemd со всей функциональностью; - все дистрибутивы точно так же молча потеряют содержимое mdadm-systemd, если только их профили не будут адаптированы. Кто потенциально выиграл бы из-за этого переезда, если бы он случился? - никто; экономия нескольких килобайт не стоит и разговора. Что в итоге? Неприятности у пользователей systemd вследствие переезда серьёзные, выигрыша нет. > > +%package doc > > +Summary: Optional documentation for %name > > +Group: System/Configuration/Hardware > > +BuildArch: noarch > > +%description doc > > +%summary > > Зачем отдельный пакет такого размера (20K) без зависимостей? > Чтобы потерять /usr/share/doc/mdadm*/ANNOUNCE*? Какие файлы были перенесены в этот mdadm-doc? $ rpmquery -lp mdadm-doc-4.0-alt2.noarch.rpm /usr/share/doc/mdadm-doc-4.0 /usr/share/doc/mdadm-doc-4.0/ANNOUNCE-4.0 /usr/share/doc/mdadm-doc-4.0/ChangeLog.bz2 /usr/share/doc/mdadm-doc-4.0/README.recipes /usr/share/doc/mdadm-doc-4.0/TODO /usr/share/doc/mdadm-doc-4.0/mdadm.conf-example Кто пострадал бы из-за этого переезда, если бы он случился? - все, у кого обновится пакет mdadm, например, в результате dist-upgrade, молча потеряют содержимое mdadm-doc; - все дистрибутивы точно так же молча потеряют содержимое mdadm-doc, если только их профили не будут адаптированы. Кто потенциально выиграл бы из-за этого переезда, если бы он случился? - никто; все, кому нужно сэкономить на документации, используют --excludedocs. Что в итоге? Неприятности вследствие переезда серьёзные, выигрыша нет. Суммируя всё вышесказанное, следствием обсуждаемого расчленения пакета mdadm стали бы существенные неприятности почти везде, где он сейчас используется, без какого-либо выигрыша, ради которого стоило бы затевать что-либо подобное. Я надеюсь, что эта была последняя попытка паразитного расчленения пакета. -- ldv