Так и задумано, 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.