Bug 28284 - 211-firmware blocks firmware-extract, firmware-tools and similar packages
: 211-firmware blocks firmware-extract, firmware-tools and similar packages
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/sisyphus_check)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2012-12-27 23:10 by
Modified: 2013-01-24 04:50 (History)


Attachments
пример. (173.73 KB, application/x-rpm)
2012-12-27 23:10, viy
no flags Details
еще один пример (88.77 KB, application/x-rpm)
2012-12-28 00:30, viy
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-12-27 23:10:26
Created an attachment (id=5689) [details]
пример.

В пакетах с названиями firmware-extract, formware-tools происходит ложное
срабатывание на firmware:

/.out/firmware-extract-2.0.13-alt1_4.1.noarch.rpm: firmware files should be
placed in /lib/firmware/
sisyphus_check: check-firmware ERROR: firmware packaging violation

/.out/firmware-tools-2.1.15-alt1_1.3.noarch.rpm: firmware files should be
placed in /lib/firmware/
sisyphus_check: check-firmware ERROR: firmware packaging violation
hsh-rebuild: firmware-tools-2.1.15-alt1_1.3.src.rpm: sisyphus_check failed.

firmware там, естественно, нету.
------- Comment #1 From 2012-12-28 00:30:35 -------
Created an attachment (id=5690) [details]
еще один пример
------- Comment #2 From 2013-01-09 22:11:20 -------
напомню про баг на sisyphus_check
------- Comment #3 From 2013-01-09 22:17:26 -------
Что вы предлагаете с этим делать?  Отменять правило, что в пакетах firmware-*
находится только firmware?
------- Comment #4 From 2013-01-09 22:21:56 -------
Добавить список исключений.

Состоящий из
firmware-extract
firmware-tools
и плагин к firmware-tools,
firmware-addon-dell

Это проще, чем пытаться заскриптовать поиск firmware blobs.
------- Comment #5 From 2013-01-24 01:40:24 -------
Мне нужны исходники или бинарники всех пакетов-исключений, чтобы проверить
изменение.
------- Comment #6 From 2013-01-24 01:58:19 -------
А не проще (правильнее?) убрать такой префикс у пакета с утилитами ?

У нас уже есть прецеденты: isight-firmware-tools, mstflint, b43-fwcutter,
bcm43xx-fwcutter и т.д. Все эти пакеты содержат утилиты для работы с firmware.

Вместе с тем, сейчас firmware-* содержат только firmware.

Может тогда разрешить хранить /lib/firmware/* в пакетах не начинающихся с
firmware- для симметрии ? :)
------- Comment #7 From 2013-01-24 02:03:52 -------
firmware-extract
firmware-tools
во вложениях,
https://bugzilla.altlinux.org/attachment.cgi?id=5689
https://bugzilla.altlinux.org/attachment.cgi?id=5690

а что касается firmware-addon-dell, то потенциально в будущем таких пакетов
может
быть несколько, я его сейчас переименую в firmware-tools-addon-dell,
тогда в исключение можно будет вставить маску firmware-tools-addon-*
------- Comment #8 From 2013-01-24 02:06:53 -------
(In reply to comment #6)
> А не проще (правильнее?) убрать такой префикс у пакета с утилитами ?

Что же ты раньше молчал?  Конечно, проще и правильнее. :)
Но пользователи все равно хотят...
------- Comment #9 From 2013-01-24 02:10:09 -------
(В ответ на комментарий №6)
> А не проще (правильнее?) убрать такой префикс у пакета с утилитами ?
> 
> У нас уже есть прецеденты: isight-firmware-tools, mstflint, b43-fwcutter,
> bcm43xx-fwcutter и т.д. Все эти пакеты содержат утилиты для работы с firmware.

пользователей путать...
Это же _явные_ исключения, т.е. проверено вручную теплым ламповым способом.

Не нужно пытаться загонять жизнь в простые правила -
а то будет как анекдот про гениального механика.
Изобрел механического робота-парикмахера.
Ему возражают, что лица у всех людей разные -
говорит - ничего, это только первый раз :)
------- Comment #10 From 2013-01-24 02:22:20 -------
(В ответ на комментарий №8)
> Что же ты раньше молчал?  Конечно, проще и правильнее. :)

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

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

Учитывая источник этих утилит, то предлагаю dell-*.

> Но пользователи все равно хотят...

Хм. Веский аргумент.
------- Comment #11 From 2013-01-24 02:29:36 -------
(В ответ на комментарий №9)
> пользователей путать...

А мне кажется, что путать - это тогда когда называешь firmware-* то что уже 4
года как обозначает только фирмварь. Кстати, вас не смущает, что kernel-image-*
это только образы ядра ? :)

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

> Это же _явные_ исключения, т.е. проверено вручную теплым ламповым способом.

Я лишь согласен с тем, что утилиты для firmware стоит именовать единообразно.
Есть предложения, кроме длинного firmware-tools-* ?
------- Comment #12 From 2013-01-24 02:31:44 -------
(В ответ на комментарий №10)
> Сначала я хотел предложить какой-нибудь общий префикс для пакетов для таких
> утилит (отличный от firmware-) чтобы избежать необходимости исключений
> поимённо, но так как пакеты с утилитами уже присутствуют в репозитории в
> довольно большом количестве, то такого рода полиси по именованию теряет смысл.

В каком-то смысле это вылезла недоработка в firmware полиси.
В чем проблема:
firmware это более общее понятие, чем то, покрывается с помощью
firmware-policy.
Скажем, arduino bootloader это firmware, но заливается он с помощью avrdude.

Есть подкласс firmware, это kernel modules firmware, которые заливаются в
устройство с помощью ядра.

поэтому если и вводить префикс, то 
kernel-firmware-*
тогда бы и путаницы не было.
------- Comment #13 From 2013-01-24 02:50:58 -------
(В ответ на комментарий №12)
> В каком-то смысле это вылезла недоработка в firmware полиси.
> В чем проблема:
> firmware это более общее понятие, чем то, покрывается с помощью
> firmware-policy.
> Скажем, arduino bootloader это firmware, но заливается он с помощью avrdude.

Firmware это вообще понятие очень общее. К сожалению всего предугадать нельзя.
Но можно следовать уже установленным правилам, если они не противоречат чему-то
явно и это непреодолимо (для этого вводятся исключения).

Так исторически сложилось, что firmware-* это префикс для пакетов с
/lib/firmware/*. Если намечаются другие классы firmware с формализованными
правилами, то им лучше дать другой общий префикс.

> поэтому если и вводить префикс, то 
> kernel-firmware-*

Согласен, но фарш, как известно, нельзя провернуть назад.
Таких пакетов уже 35 штук.
------- Comment #14 From 2013-01-24 03:15:38 -------
> Согласен, но фарш, как известно, нельзя провернуть назад.
> Таких пакетов уже 35 штук.

В принципе, запихнуть можно,
готов предложить помощь - сделать NMU с переменованием.

C текущимb правилами проблема в том, что приходится уже слишком извращаться,
чтобы дать пакету осмысленное имя, и и не использовать firmware-tools.

Поэтому вроде бы и есть сысл в ручном списке исключений -
если пакет проверен руками и в нем заведомо нет kernel firmware,
то зачем его роботом еще проверять?
------- Comment #15 From 2013-01-24 03:40:55 -------
(В ответ на комментарий №14)
> > Согласен, но фарш, как известно, нельзя провернуть назад.
> > Таких пакетов уже 35 штук.
> 
> В принципе, запихнуть можно,
> готов предложить помощь - сделать NMU с переменованием.

Видите ли проблема с именованием пакетов не только, что их достаточно много и
мантейнеры уже достаточно давно используют это именование, но и в том, что за
эти 4 года эти имена попали в разного рода профили сборки образов. Менять
именование это обречь массу людей на гемор.

Не знаю как Дима, но лично я считаю, что такое старое (и хорошо
формализованное) правило не стоит менять. Гораздо проще придумать _новому_
пакету другое название.

> C текущимb правилами проблема в том, что приходится уже слишком извращаться,
> чтобы дать пакету осмысленное имя, и и не использовать firmware-tools.

Я верю, что у вас хорошая фантазия и вы можете мыслить вне банальностей типа
firmware-tools-* :)

Но даже если лучшего префикса, чем firmware-tools-* не придумается, то лучше уж
добавить в исключения его, а не поимённое перечисление тех пакетов, где не
хватило фантазии.

> Поэтому вроде бы и есть сысл в ручном списке исключений -
> если пакет проверен руками

Простите, кем проверен? человеком? Люди имеют обыкновение ошибаться и те кто
побывал на incoming это отлично знают.

> и в нем заведомо нет kernel firmware,
> то зачем его роботом еще проверять?

Чтобы исключить ошибки.

Если бы дело было так просто как вы говорите, то в автоматизированных средствах
проверки пакетов до публикации в сизиф не было бы нужды. Все эти проверки
появились из-за ошибок мантейнеров, регулярных ошибок. Одной из первых таких
проверок был как раз sisyphus_check. Он позволял проверять srpm пакет на общие
грубые ошибки _до_ отправки в incoming.
------- Comment #16 From 2013-01-24 03:46:36 -------
В общем, я понимаю, что лучшее враг хорошего, поэтому в данном случае не
настаиваю, возможно, просто фантазии не хватает переименовать пакеты...
------- Comment #17 From 2013-01-24 03:59:47 -------
(In reply to comment #15)
> (В ответ на комментарий №14)
> > > Согласен, но фарш, как известно, нельзя провернуть назад.
> > > Таких пакетов уже 35 штук.
> > 
> > В принципе, запихнуть можно,
> > готов предложить помощь - сделать NMU с переменованием.
> 
> Видите ли проблема с именованием пакетов не только, что их достаточно много и
> мантейнеры уже достаточно давно используют это именование, но и в том, что за
> эти 4 года эти имена попали в разного рода профили сборки образов. Менять
> именование это обречь массу людей на гемор.

Я надеюсь, что в форма firmware-* не используется ни в одном профиле, иначе под
нее попадает много старых редкоиспользуемых пакетов.

> > C текущимb правилами проблема в том, что приходится уже слишком извращаться,
> > чтобы дать пакету осмысленное имя, и и не использовать firmware-tools.
> 
> Я верю, что у вас хорошая фантазия и вы можете мыслить вне банальностей типа
> firmware-tools-* :)

Традиция именования пакетов *-tools более древняя, чем firmware-*.
Но при этом в федорном пакете firmware-tools находятся файлы
/usr/lib*/python*/site-packages/firmwaretools
/usr/sbin/firmwaretool
что наводит на мысль о более точном имени для пакета (без дефиса в имени).
Хотя там есть и /usr/share/firmware-tools/.

Пакет firmware-extract - это на самом деле плагин для firmware-tools.

В общем, у меня складывается ощущение, что если и стоит добавлять исключения,
то только для имен firmware-tools и firmware-tools-*.

> > Поэтому вроде бы и есть сысл в ручном списке исключений -
> > если пакет проверен руками
> 
> Простите, кем проверен? человеком? Люди имеют обыкновение ошибаться и те кто
> побывал на incoming это отлично знают.
> 
> > и в нем заведомо нет kernel firmware,
> > то зачем его роботом еще проверять?
> 
> Чтобы исключить ошибки.

В любом случае речь идет не об отключении проверки firmware для пакетов
firmware-tools и пр., а об изменении сути этой проверки для этих пакетов: для
них будет применятся правило, которое применяется для не-firmware пакетов, т.е.
в них тогда будет запрещено /lib/firmware/*.
------- Comment #18 From 2013-01-24 04:13:49 -------
(В ответ на комментарий №17)
> В общем, у меня складывается ощущение, что если и стоит добавлять исключения,
> то только для имен firmware-tools и firmware-tools-*.

Ок, конечно. я тогда переименую их в firmware-tools-extract и
firmwatre-tools-addon-dell .
------- Comment #19 From 2013-01-24 04:46:33 -------
sisyphus_check-0.8.37-alt1 -> sisyphus:

* Thu Jan 24 2013 Dmitry V. Levin <ldv@altlinux> 0.8.37-alt1
- 211-check-firmware: added exception for firmware-tools and
  firmware-tools-* (closes: #28284).
- fhs: added exception for msp430* packages (closes: #28286).
------- Comment #20 From 2013-01-24 04:50:03 -------
Спасибо!