Автор: Андрей Русев Цитата:я полагаю, необходимо сначала сделать catopen("csp_error_messages.cat")
Вы ошибаетесь, и я пояснил выше почему.
Если вы про ссылку выше, то вообще говоря смысл кодировки CP_ACP под Unix мало понятен. Windows API определяет её как "The system default Windows ANSI code page": что это такое под Unix'ом - одному богу (и, возможно, вам) известно. Однако коли речь идет о сообщениях, выводимых юзеру, то вряд ли он будет ожидать их в чем-нибудь окромя $LANG.
Тем не менее, допустим, что в ваших словах есть какая-то логика, которую мне не дано понять. Но почему тогда у всех ваших загружаемых модулей имеются собственнные каталоги сообщений и все они (кроме librdrjacarta.so и librdresmart*.so) следуют именно тому поведению, что сначала вызывают, например, catopen("librdrrutoken.cat") и только потом ищут свой каталог сообщений в /opt/cprocsp/share/locale? Это опять же легко видеть, если запустить из-под strace и почитать, какие файлы пытаются открываться. То есть тут имеется противоречие с любой логикой, которая может стоять за существующей процедеруй открытия "csp_error_messages.cat".
Вот, кстати, кусочек из лога выше:
Код:
openat(AT_FDCWD, "/usr/share/locale/ru_RU.UTF-8/librdrric.cat", O_RDONLY) = -1 ENOENT (Нет такого файла или каталога)
openat(AT_FDCWD, "/usr/share/locale/ru_RU.UTF-8/LC_MESSAGES/librdrric.cat", O_RDONLY) = -1 ENOENT (Нет такого файла или каталога)
openat(AT_FDCWD, "/usr/share/locale/ru/librdrric.cat", O_RDONLY) = -1 ENOENT (Нет такого файла или каталога)
openat(AT_FDCWD, "/usr/share/locale/ru/LC_MESSAGES/librdrric.cat", O_RDONLY) = -1 ENOENT (Нет такого файла или каталога)
openat(AT_FDCWD, "/opt/cprocsp/share/locale/default/LC_MESSAGES/../../ru_RU.UTF-8/librdrric.cat", O_RDONLY) = -1 ENOENT (Нет такого файла или каталога)
openat(AT_FDCWD, "/opt/cprocsp/share/locale/default/LC_MESSAGES/librdrric.cat", O_RDONLY) = 3
Автор: Андрей Русев
Выбор папки /opt соответствует стандарту FHS.
Повторюсь, это не вам в укор было. В /opt никогда никто не ставился, не организовав помойку. Будь хоть сам Intel - результат один.
Автор: Андрей Русев
Проблема с зависимостями от пакетов понятна, но она заключается во фрагментированности Linux, а не нашем дистрибутиве.
Очень может быть. Тем не менее, смею полагать, что для большинства Debian-образных дистрибутивов можно более-менее малой кровью написать один набор скриптов и метаинфы для нативной запаковки. А принимая во внимание нарастающую популярность Ubuntu, существующую популярность Debian (как минимум в серверном сегменте) и закат CentOS, из которого, наверное, половина сбежит в Ubuntu, то это довольно приличная доля юзеров из тех, что пользуют Linux.
Автор: Андрей Русев
О каких родных для debian концепциях речь?
Уффф... да их много:
1) Файлы *.a и *.so, если у библиотеки версионированное SONAME используются только в -dev пакетах
1a) Файлы подключаемых модулей приложения (типа ваших ридеров) не ставятся в каталог, который находится в кэше динамического линкера - для этого в каталоге lib заводится отдельная директория приложения, в которой размещаются плагины.
2) Для выбора конкретного приложения, когда есть несколько вариантов (например, oauthapp и его гуёвый аналог), в дебианах используется система alternatives, а не химия в конфиге с бэкапом старого значения, которая ломается, если порядок деинсталяции не соответствует порядку инсталяции, кроме того, это позволяет юзеру, имеющему root-доступ легко переключать это уже в процессе эксплуатации системы, исходя из собственных нужд.
3) Вместо того, чтобы в postinst скриптах дергать cpconfig для того, чтобы добавить в конфиг, а в prerm скриптах удалять изменения, внесенные при установке, принято заводить соответсвующую директорию с суфиксом .d, в которую ставит свой файл каждый пакет, желающий что-то сконфигурить, и перегенерировать весь конфиг при установке или удалении пакета, который вносит изменения. Так вы избавляетесь от задачи следить за тем, что при удалении вы выполняете строго обратные действия (что у вас, кстати, не всегда соблюдается). Для локальных изменений конфигураций заводится файл с именем типа local и при перегенерации он запускается последним. Скрипт, который выполняет перегенерацию, может быть установлен base-пакетом. Впрочем, подобная концепция была в последние годы и во многих redhat'овских поделках использована, наконец-то.
4) Для динамических библиотек создаётся файл shlibs, чтобы при подготовке других пакетов, которые зависят от вашего продукта, зависимости могли вычисляться автоматически.
5) Целая кагорта замечаний может быть высказана в отношении init-скрипта /etc/init.d/cprocsp - главным образом его стоило бы разбить как минимум на часть, которая запускает КС2, и на часть, которая проверяет контрольные суммы. А ещё лучше в качестве альтернативы systemd юниты сделать, хотя понимаю, что не везде оно есть.
6) Нельзя из postinit-скрипта удалять файлы, которые установлены пакетом.
7-N) Список можно ещё продолжать, но проще почитать debian policy если интересно
Автор: Андрей Русев
Кажется всё, что вам реально нужно было сделать, это метапакет, который зависел бы от GUI/PCSC-пакетов в вашей ОС и от CSP.
Не все так просто. shlibs-файлы не сгенерятся таким образом. GUI-пакет для cloud не на всех версиях дистрибутива может быть установлен, потому что та версия webkit, которую вы используете в GUI-авторизовалке, уже разложилась не плесень и на липовый мёд. Кроме того, окромя GUI и PCSC у вас там тянется perl и даже TeX (для xer2pdf или как она там называется). А кроме того: судя по всему невозможно одновременно использоваться КС1 и КС2 - который из них должен тянуть метапакет? В общем, сначала я тоже думал сделать метапакет, но вскоре отказался от этой идеи.
Если хотите, я могу выложить результаты этой работы, авось вам пригодится.
Автор: Андрей Русев
jacarta и esmart - это не наши пакеты, нарекания по ним партнёры устраняют очень медленно или никогда.
Печально, что у вас такие партнёры, но, наверное, стоит им хотя бы сообщить об этой проблеме.
Отредактировано пользователем 9 марта 2021 г. 16:30:16(UTC)
| Причина: Не указана