ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Invalid access mode for verify-file | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Evgenii Terechkov <evg> |
| Component: | lftp | Assignee: | placeholder <placeholder> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | minor | ||
| Priority: | P2 | CC: | at, glebfm, ldv, placeholder |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
Незапускаемость была специально сделана для того, чтобы подавить перловые зависимости, которые порождает этот файл. Ясно. Просто я спек этой сборки не смотрел. В своей делал: ~$ 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). |
$ lftp /usr/share/lftp/verify-file: Отказано в доступе. :~> Неакуратненько. chmod 755 ?