from devel@: =============================================================================== P.S.: дарю идею - сделать юниттест, проверяющий все файлы пакета на предмет текстового вхождения %name-buildroot (имени каталога, где происходила сборка). Думаю, это было бы сильно полезнее против гораздо более разломанных пакетов. Или это на sisyphus_check? =============================================================================== Временами попадаются такие больные на голову системы сборки, которые пути сборки в итоговые файлы записывают. Временами это вылезает очень неприятной неработоспособностью пакетов. Я больше склоняюсь к тому, чтобы по результату этого теста выдавать предупреждение. Вот пример перед глазами - пакеты с байт-кодом для emacs ссылаются на исходные *.el-файлы в %name-buildroot если они есть, иначе прозрачно переключаются на нужные .el-файлы (вижу на примере emacs-jabber). Насколько я понял, это не чинится.
> Временами попадаются такие больные на голову системы сборки, которые пути сборки > в итоговые файлы записывают. Временами это вылезает очень неприятной > неработоспособностью пакетов. Иногда встречается. > Я больше склоняюсь к тому, чтобы по результату этого теста выдавать > предупреждение. Вот пример перед глазами - пакеты с байт-кодом для emacs > ссылаются на исходные *.el-файлы в %name-buildroot если они есть, иначе > прозрачно переключаются на нужные .el-файлы (вижу на примере emacs-jabber). > Насколько я понял, это не чинится. Иногда не чинится.
(In reply to comment #1) > > Насколько я понял, это не чинится > Иногда не чинится. В данном частном случае - байт-код емакса. Ну а чаще такое можно и нужно чинить.
тест соответствующий я написал, результаты опубликую в devel@. но как показал анализ. не всегда такое вхождение является ошибкой. поэтому предлагаю баг закрыть. это не для sisyphus_check.
Пусть теперь на rpm-build повисит.
(In reply to comment #3) > тест соответствующий я написал, > результаты опубликую в devel@. > но как показал анализ. > не всегда такое вхождение является ошибкой. Да я и сам об этом же пишу - лучше warning показывать с указанием, чего и где. > поэтому предлагаю баг закрыть. это не для sisyphus_check. А мне вот интересно, что по этому поводу думает ldv@. И да, скорее это уж на rpm-build стойло бы повесить. А дублирование с результатами repocop, я думаю, небезсмысленно - т.к. вывод rpm-build в общем случае не публикуется.
rpm-build может избить невиновных...
