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

Ясно. Просто я спек этой сборки не смотрел.

В своей делал:

~$ GR perl ~/RPM/SPECS/lftp.spec
AutoReq: yes, noperl
Recommends: perl-String-CRC32

Или так ещё хуже?

Recommends?

(In reply to comment #3)
> Recommends?

# Due to %_datadir/%name/{convert-netscape-cookies,verify-file}.
AutoReq: yes, noperl
...
Recommends: perl-String-CRC32
...
%attr(755,root,root) %_datadir/%name/*

perl-base, достаточный для большинства из этих скриптов, в системе будет всё
равно. Таким образом, из коробки будет работать часть скриптов. Вторая
заработает, если установить дополнительный пакет(ы). Думаю, это более
"дистрибутивный" и простой подход, чем рекомендовать пользователю сменить права
на файлы и доустановить пакеты.

Алексей, что делать с этим пакетом в свете наступающих вездесущих find-requires?

(In reply to comment #5)
> Алексей, что делать с этим пакетом в свете наступающих вездесущих find-requires?

chmod 755 и будь что будет или крошить мельче. :-)

Зависимости у этого скрипта ищутся правильно.  Но String::CRC32 -- это
нестандартный модуль, его давно никто не собирал, и уже вышло две новые версии. 
Но этот модуль и текущем виде хорошо работает.  Специфика "use String::CRC32"
такова, что если бы этот модуль был сломан, то поиск зависимостей просто отвалил
бы.  С "require" несколько иное дело, поскольку "require" не активизируется на
стадии syntax check.  Однако в целом обычно все поломанные модули удается
обнаружить, даже если они требуются через "require".

Recommends это глупость.  То есть это дебиановская фишка для "настройки
вручную", наравне с debconf.  У нас никакой настройки вручную не предусмотрено,
а даже совсем наоборот -- есть APT::Install::Virtual для подавления вопросов.  В
чрут recommends будет ставиться или нет?  И как тогда buildreq должен
фиксировать сборочные зависимости?

И как собственно perl.req должен проставлять зависимости типа Recommends?  А
если вручную их писать то всё дело на смарку.  То есть идея фикс это не писать
вручную зависимости ВООБЩЕ -- либо find-requires, либо buildreq делают 99.9%
работы.  Это освобождает maintainer'ов от мартишкиного труда.  А recommends
склоняет maintainer'ов опять заниматься мартышкиным трудом.  Некоторые
maintainer'ы очень хорошие люди, но даже симлинк не могут правильно поставить. 
А грамотные зависимости это всё же посложнее симлинков.

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

(In reply to comment #7)
> Так что мое мнение простое -- это скрипт либо нужен, и тогда он должен работать
> по зависимостям.  Либо не нужен.

Подписываюсь под каждым словом.

Recommends: же в своей сборке (и я не утверждаю, что надо так делать :-)) я
ставил для чтения ЧЕЛОВЕКОМ (в Summary) - чтоб он сразу видел, что ставить,
когда скрипт не работает. Я так же сделал и для icewm, iftop, mutt (первый
настроен из коробки на остальные два, но не требует их. Кстати, не думаю что
хоть один автопроверяльщик это сам определит, в конфиге то). И не думаю, что это
плохо, если позиционировать тэг как предназначенный для чтения людьми.

Fixed in 3.5.10-alt2 (restored permissions, disabled dependencies).