Bug 28284
| Summary: | 211-firmware blocks firmware-extract, firmware-tools and similar packages | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | viy <viy> | ||||||
| Component: | sisyphus_check | Assignee: | Dmitry V. Levin <ldv> | ||||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | at, glebfm, imz, ldv, legion, placeholder | ||||||
| Version: | unstable | ||||||||
| Hardware: | all | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
Created attachment 5690 [details]
еще один пример
напомню про баг на sisyphus_check Что вы предлагаете с этим делать? Отменять правило, что в пакетах firmware-* находится только firmware? Добавить список исключений. Состоящий из firmware-extract firmware-tools и плагин к firmware-tools, firmware-addon-dell Это проще, чем пытаться заскриптовать поиск firmware blobs. Мне нужны исходники или бинарники всех пакетов-исключений, чтобы проверить изменение. А не проще (правильнее?) убрать такой префикс у пакета с утилитами ? У нас уже есть прецеденты: isight-firmware-tools, mstflint, b43-fwcutter, bcm43xx-fwcutter и т.д. Все эти пакеты содержат утилиты для работы с firmware. Вместе с тем, сейчас firmware-* содержат только firmware. Может тогда разрешить хранить /lib/firmware/* в пакетах не начинающихся с firmware- для симметрии ? :) 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-* (In reply to comment #6) > А не проще (правильнее?) убрать такой префикс у пакета с утилитами ? Что же ты раньше молчал? Конечно, проще и правильнее. :) Но пользователи все равно хотят... (В ответ на комментарий №6) > А не проще (правильнее?) убрать такой префикс у пакета с утилитами ? > > У нас уже есть прецеденты: isight-firmware-tools, mstflint, b43-fwcutter, > bcm43xx-fwcutter и т.д. Все эти пакеты содержат утилиты для работы с firmware. пользователей путать... Это же _явные_ исключения, т.е. проверено вручную теплым ламповым способом. Не нужно пытаться загонять жизнь в простые правила - а то будет как анекдот про гениального механика. Изобрел механического робота-парикмахера. Ему возражают, что лица у всех людей разные - говорит - ничего, это только первый раз :) (В ответ на комментарий №8) > Что же ты раньше молчал? Конечно, проще и правильнее. :) Дим, прости меня, но я видел эту багу, но мне в голову не пришло, что ты решишь вносить исключения в этом случае. Сначала я хотел предложить какой-нибудь общий префикс для пакетов для таких утилит (отличный от firmware-) чтобы избежать необходимости исключений поимённо, но так как пакеты с утилитами уже присутствуют в репозитории в довольно большом количестве, то такого рода полиси по именованию теряет смысл. Учитывая источник этих утилит, то предлагаю dell-*. > Но пользователи все равно хотят... Хм. Веский аргумент. (В ответ на комментарий №9) > пользователей путать... А мне кажется, что путать - это тогда когда называешь firmware-* то что уже 4 года как обозначает только фирмварь. Кстати, вас не смущает, что kernel-image-* это только образы ядра ? :) Правила наименования для того и нужны, чтобы не путать пользователя. Этот пакет для этого и сделан. > Это же _явные_ исключения, т.е. проверено вручную теплым ламповым способом. Я лишь согласен с тем, что утилиты для firmware стоит именовать единообразно. Есть предложения, кроме длинного firmware-tools-* ? (В ответ на комментарий №10) > Сначала я хотел предложить какой-нибудь общий префикс для пакетов для таких > утилит (отличный от firmware-) чтобы избежать необходимости исключений > поимённо, но так как пакеты с утилитами уже присутствуют в репозитории в > довольно большом количестве, то такого рода полиси по именованию теряет смысл. В каком-то смысле это вылезла недоработка в firmware полиси. В чем проблема: firmware это более общее понятие, чем то, покрывается с помощью firmware-policy. Скажем, arduino bootloader это firmware, но заливается он с помощью avrdude. Есть подкласс firmware, это kernel modules firmware, которые заливаются в устройство с помощью ядра. поэтому если и вводить префикс, то kernel-firmware-* тогда бы и путаницы не было. (В ответ на комментарий №12) > В каком-то смысле это вылезла недоработка в firmware полиси. > В чем проблема: > firmware это более общее понятие, чем то, покрывается с помощью > firmware-policy. > Скажем, arduino bootloader это firmware, но заливается он с помощью avrdude. Firmware это вообще понятие очень общее. К сожалению всего предугадать нельзя. Но можно следовать уже установленным правилам, если они не противоречат чему-то явно и это непреодолимо (для этого вводятся исключения). Так исторически сложилось, что firmware-* это префикс для пакетов с /lib/firmware/*. Если намечаются другие классы firmware с формализованными правилами, то им лучше дать другой общий префикс. > поэтому если и вводить префикс, то > kernel-firmware-* Согласен, но фарш, как известно, нельзя провернуть назад. Таких пакетов уже 35 штук. > Согласен, но фарш, как известно, нельзя провернуть назад.
> Таких пакетов уже 35 штук.
В принципе, запихнуть можно,
готов предложить помощь - сделать NMU с переменованием.
C текущимb правилами проблема в том, что приходится уже слишком извращаться,
чтобы дать пакету осмысленное имя, и и не использовать firmware-tools.
Поэтому вроде бы и есть сысл в ручном списке исключений -
если пакет проверен руками и в нем заведомо нет kernel firmware,
то зачем его роботом еще проверять?
(В ответ на комментарий №14) > > Согласен, но фарш, как известно, нельзя провернуть назад. > > Таких пакетов уже 35 штук. > > В принципе, запихнуть можно, > готов предложить помощь - сделать NMU с переменованием. Видите ли проблема с именованием пакетов не только, что их достаточно много и мантейнеры уже достаточно давно используют это именование, но и в том, что за эти 4 года эти имена попали в разного рода профили сборки образов. Менять именование это обречь массу людей на гемор. Не знаю как Дима, но лично я считаю, что такое старое (и хорошо формализованное) правило не стоит менять. Гораздо проще придумать _новому_ пакету другое название. > C текущимb правилами проблема в том, что приходится уже слишком извращаться, > чтобы дать пакету осмысленное имя, и и не использовать firmware-tools. Я верю, что у вас хорошая фантазия и вы можете мыслить вне банальностей типа firmware-tools-* :) Но даже если лучшего префикса, чем firmware-tools-* не придумается, то лучше уж добавить в исключения его, а не поимённое перечисление тех пакетов, где не хватило фантазии. > Поэтому вроде бы и есть сысл в ручном списке исключений - > если пакет проверен руками Простите, кем проверен? человеком? Люди имеют обыкновение ошибаться и те кто побывал на incoming это отлично знают. > и в нем заведомо нет kernel firmware, > то зачем его роботом еще проверять? Чтобы исключить ошибки. Если бы дело было так просто как вы говорите, то в автоматизированных средствах проверки пакетов до публикации в сизиф не было бы нужды. Все эти проверки появились из-за ошибок мантейнеров, регулярных ошибок. Одной из первых таких проверок был как раз sisyphus_check. Он позволял проверять srpm пакет на общие грубые ошибки _до_ отправки в incoming. В общем, я понимаю, что лучшее враг хорошего, поэтому в данном случае не настаиваю, возможно, просто фантазии не хватает переименовать пакеты... (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/*. (В ответ на комментарий №17)
> В общем, у меня складывается ощущение, что если и стоит добавлять исключения,
> то только для имен firmware-tools и firmware-tools-*.
Ок, конечно. я тогда переименую их в firmware-tools-extract и firmwatre-tools-addon-dell .
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). Спасибо! |
Description
viy 2012-12-27 23:10:26 MSKCreated attachment 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 там, естественно, нету.