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

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

[Dmitry V. Levin]

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

Hi,

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 <gremlin@altlinux>
> Date:   Thu Nov 2 11:52:57 2017 +0300
> 
>     split to subpackages to avoid parasitic dependencies;

Заменяем паразитные зависимости на паразитные пакеты?
С какими зависимостями боремся-то?  У mdadm и так зависимостей мало.

>     disable running raidtabtomdadm.sh (there are no raidtabs left)
> 
> Full diff since common ancestor `270b6b59826e674d04a51912755bb47c991dc139' follows:
> diff --git a/mdadm.spec b/mdadm.spec
> index d17566a..9b1cdbc 100644
> --- a/mdadm.spec
> +++ b/mdadm.spec
> @@ -2,7 +2,7 @@
>  
>  Name: mdadm
>  Version: 4.0
> -Release: alt1
> +Release: alt2
>  
>  Summary: A tool for managing Soft RAID under Linux
>  License: GPLv2+
> @@ -15,9 +15,6 @@ Source: %name-%version-%release.tar
>  BuildRequires: binutils-devel
>  %{?_enable_cluster:BuildRequires: libcorosync2-devel libdlm-devel}
>  
> -# due to /lib/udev/rules.d/64-md-raid.rules
> -Conflicts: udev < 151
> -
>  %description
>  mdadm is a program that can be used to create, manage, and monitor
>  Linux MD (Software RAID) devices.
> @@ -28,6 +25,36 @@ program, and it can perform (almost) all functions without a
>  configuration file (that a config file can be used to help with
>  some common tasks).
>  
> +%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.
Зачем отдельный пакет?

> +%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?

> +%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 в разных пакетах?

> +%package doc
> +Summary: Optional documentation for %name
> +Group: System/Configuration/Hardware
> +BuildArch: noarch
> +%description doc
> +%summary

Зачем отдельный пакет такого размера (20K) без зависимостей?
Чтобы потерять /usr/share/doc/mdadm*/ANNOUNCE*?


-- 
ldv

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

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

[Dmitry V. Levin]

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

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 <gremlin@altlinux>
> > 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

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

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

[Anton Farygin]

03.11.2017 03:51, Dmitry V. Levin пишет:
> Я надеюсь, что эта была последняя попытка паразитного расчленения пакета.

Предлагаю, можно просто договориться что для уже существующих пакетов 
начинающие ментейнеры с низким уровнем опыта работы над пакетной базой 
ALT (вроде Гремлина) не будут делать ненужную работу не посоветовавшись 
с более опытными коллегами.

Это ведь не сложно - написать письмо в devel@ со словами "я хочу сделать 
то-то то-то".

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

[Michael Shigorin]

On Fri, Nov 03, 2017 at 03:51:54AM +0300, Dmitry V. Levin wrote:
> Суммируя всё вышесказанное, следствием обсуждаемого расчленения
> пакета mdadm стали бы существенные неприятности почти везде,
> где он сейчас используется, без какого-либо выигрыша, ради
> которого стоило бы затевать что-либо подобное.

Зафиксирую уже озвученное голосом: у нас в случае реальной
необходимости выделения существенных подпакетов принято
базовую функциональность также выносить в, скажем, %name-base,
а %name превращать в метапакет, который вытягивает по возможности
всё, что ожидал пользователь предыдущей сборки пакета.

Возможно, стоит набросать какое-нить Package Split-up
mini-Policy, если требуется больше абзаца и примера.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

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

[Dmitry V. Levin]

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

On Fri, Nov 03, 2017 at 04:26:20PM +0300, Michael Shigorin wrote:
> On Fri, Nov 03, 2017 at 03:51:54AM +0300, Dmitry V. Levin wrote:
> > Суммируя всё вышесказанное, следствием обсуждаемого расчленения
> > пакета mdadm стали бы существенные неприятности почти везде,
> > где он сейчас используется, без какого-либо выигрыша, ради
> > которого стоило бы затевать что-либо подобное.
> 
> Зафиксирую уже озвученное голосом: у нас в случае реальной
> необходимости выделения существенных подпакетов принято
> базовую функциональность также выносить в, скажем, %name-base,

Так вот откуда %name-base-core-common берутся! :)


-- 
ldv

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

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

[Alexey V. Vissarionov]

[-- 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 --]