On Mon, Sep 10, 2007 at 12:39:40AM +0400, Alexey I. Froloff wrote: > * Alexey Tourbin [070910 00:14]: > > Просто раньше в find-requires была проверка на [ -x /usr/bin/tcl ]. > > Теперь ее там нет. > Вот интересно, а должны ли rpm-build-скриптовойязык требовать > обязательного наличия /usr/bin/скриптовойязык? Особенно если от > rpm-build-скриптовойязык зависит сам rpm-build? perl есть в > basesystem, но есть ещё tcl и python, а скоро может появиться и > ruby. > > Получается, дешевле вручную проставлять зависимость на > rpm-build-XXX и требовать интертрепатор, чем вносить их всех в > зависимости rpm-build... Кое-что на эту тему я написал в письме про 'tcl dependencies'. Мое мнение таково: зависимости всех популярных языков программирования должны искаться в безусловном порядке, то есть, по сути, в rpm-build в идеале должны появиться зависимости на все пакеты rpm-build-язык. Иначе мы получаем не только плавающие зависимости Requires, но и, что гораздо хуже, плавающие зависимости Provides. Особенно если пакеты возьмётся собирать какой-нибудь неофит при помощи так называемого rpmrb скрипта. Автоматически обнаружить такое обстоятельство не проще, чем выяснить, пьет ли maintainer коньяк по утрам. Но конечно, с другой стороны, нельзя тащить в базовую сборочную среду всё подряд. Прежде чем подсистема "язык-зависимости" сможет стать кандидатом на внесение в зависимости rpm-build, она должна отвечать целому ряду требований. Первое требование такое: язык должен широко и незавимо использоваться. То есть его скритпы должны всплывать "тут и там", а не только в специфических для этого языка пакетах. Если все языковые пакеты как один называются язык-*, то нет смысла вносить это в базовую сборочную среду, а есть смысл написать полиси для сборки язык-* пакетов. Конечно, все реальные случаи скорее "серые". Но не безнадёжно серые. Далее, нужено очень квалифицированный maintainer, который, во-первых, способен самостоятельно написать скрипты поиска зависимостей (или хотя бы хорошо разобраться в тех, которые он утащил из другого дистрибутива), а также "всё понимать" и, следовательно, быть способным решать вопросы, когда поиск зависимостей идет не очень гладко. С таким maintainer'ом в принципе есть что дальше обсуждать.