Created attachment 12054 [details] Ожидаемый и реальный результаты вывода команды Версии пакетов: psl-0.21.1-alt3.x86_64 libpsl-0.21.1-alt3.x86_64 publicsuffix-list-dafsa-20221003-alt1.noarch publicsuffix-list-20221003-alt1.noarch Воспроизводится на всех стендах psl --print-info выдает ошибку "No builtin PSL data available" при установленных пакетах publicsuffix-list и publicsuffix-list-dafsa. Шаги воспроизведения: 1. Установить необходимые пакеты: apt-get install publicsuffix-list publicsuffix-list-dafsa psl 2. Выполнить команду: psl --print-info https://news.google.com Ожидаемый результат: Появляется информация о суффиксах Реальный результат: Появляется ошибка "No builtin PSL data available" Подробнее - на скриншоте. Дополнительно: 1. psl --print-info без аргументов дает аналогичный результат. 2. Проверялось в р10, воспроизводится.
Так и задумано, libpsl собран без builtin data. В этом случае libpsl использует только информацию из publicsuffix-list-dafsa, которая гораздо более актуальна, чем может быть builtin data на момент сборки пакета. Вариант использования libpsl без publicsuffix-list-dafsa (для чего вообще нужно builtin data) у нас не предусмотрен.
(Ответ для Mikhail Efremov на комментарий #1) > Так и задумано, libpsl собран без builtin data. В этом случае libpsl > использует только информацию из publicsuffix-list-dafsa, которая гораздо > более актуальна, чем может быть builtin data на момент сборки пакета. > Вариант использования libpsl без > publicsuffix-list-dafsa (для чего вообще нужно builtin data) у нас не > предусмотрен. Спасибо за подробное объяснение. Меня дополнительно смущает, что данные в выводе отсутствуют(при том, что publicsuffix-list-dafsa есть): "suffixes: - information not available - exceptions: - information not available - wildcards: - information not available -" Это тоже корректно?
PSL(1): --print-info print info about library builtin data Так что все правильно, builtin data действительно нет.
Некоторые приложения не умееют использовать psl_latest() вместо psl_builtin() Патчить их конечно можно, но лучше научить библиотеку жить сразу двумя способами.
(Ответ для Anton Farygin на комментарий #4) > Некоторые приложения не умееют использовать psl_latest() вместо psl_builtin() > Патчить их конечно можно, но лучше научить библиотеку жить сразу двумя > способами. А апстримы этих приложений как-то обосновывают, почему они так делают? Я вижу 2 возможные причины: 1. Может не быть внешнего dafsa-файла. У нас аргумент не работает: libpsl зависит от publicsuffix-list-dafsa и такое может быть только на поломанной системе. 2. Скорость доступа к данным, к builtin данным она должна быть выше. Вот только насколько это критично? Я к тому, что можно запатчить и саму libpsl, чтобы psl_builtin() вызывала psl_latest(), в принципе.
(Ответ для Mikhail Efremov на комментарий #5) > (Ответ для Anton Farygin на комментарий #4) > > Некоторые приложения не умееют использовать psl_latest() вместо psl_builtin() > > Патчить их конечно можно, но лучше научить библиотеку жить сразу двумя > > способами. > > А апстримы этих приложений как-то обосновывают, почему они так делают? > Я вижу 2 возможные причины: > 1. Может не быть внешнего dafsa-файла. У нас аргумент не работает: libpsl > зависит от publicsuffix-list-dafsa и такое может быть только на поломанной > системе. > 2. Скорость доступа к данным, к builtin данным она должна быть выше. Вот > только насколько это критично? Я к тому, что можно запатчить и саму libpsl, > чтобы psl_builtin() вызывала psl_latest(), в принципе. нет, я честно даже не думал у них спрашивать, там весьма странный и проблемный апстрим (это transmission). Но в целом аргумент про скорость весьма здравый. можно ещё builtin обновлять автоматически из publicsuffix-list-dafsa и пересобирать их одновременно.
Ещё нашёл такое мнение, что многие системы безопасности используют libpsl для своей работы (Cookie isolation, проверки wildcard сертификатов, возможно какие-то браузеры, которые могут использовать psl для опеределения доменов). - и в этом случае внешняя база для libpsl может быть проблемой. Лучше всего собирать и внутреннюю как fallback/надёжности и подхватывать внешнюю как основную.
(Ответ для Mikhail Efremov на комментарий #5) > можно запатчить и саму libpsl, > чтобы psl_builtin() вызывала psl_latest(), в принципе. Нет, так нельзя: возвращаемые psl_latest() ресурсы надо освобождать, в отличие от psl_builtin(). (Ответ для Anton Farygin на комментарий #6) > можно ещё builtin обновлять автоматически из publicsuffix-list-dafsa и > пересобирать их одновременно. На момент сборки используется текущий список из publicsuffix-list-dafsa. Но пересобирать каждый раз библиотеку при обновлении publicsuffix-list точно не надо, как раз для того, чтобы так не делать они и живут отдельно. Если же кто-то использует psl_builtin(), то он явно говорит "я хочу протухшие данные вместо актуальных". Ну ок, пусть будет так. Включение builtin, в принципе, грозит только тем, что библиотека станет чуть больше в размерах. Но кого это сейчас волнует. (Ответ для Anton Farygin на комментарий #7) > Ещё нашёл такое мнение, что многие системы безопасности используют libpsl > для своей работы (Cookie isolation, проверки wildcard сертификатов, > возможно какие-то браузеры, которые могут использовать psl для опеределения > доменов). - и в этом случае внешняя база для libpsl может быть проблемой. > Лучше всего собирать и внутреннюю как fallback/надёжности и подхватывать > внешнюю как основную. Я, собственно, потому и выключил builtin, что использовать лучше относительно свежие данные из publicsuffix-list.
да, зачем выключил тоже понятно. Но аргумент про то, что libpsl должна работать всегда, даже когда файл с данными не смогла загрузить - меня убедил.
libpsl-0.21.5-alt2 -> sisyphus: Wed Mar 04 2026 Mikhail Efremov <sem@altlinux> 0.21.5-alt2 - Enabled builtin PSL (closes: #44575). - Used macros from rpm-macros-meson.
