Опять %_localstatedir кусается...

rpm-build-4.0.4-alt104 produces the following diagnostics:

Checking contents of files in /usr/src/tmp/cups-filters-buildroot/ (default)
/usr/src/tmp/cups-filters-buildroot/etc/cups/cups-browsed.conf
/usr/src/tmp/cups-filters-buildroot/usr/sbin/cups-browsed
028-check_contents.brp: WARNING: Contents of files listed above match pattern /var/lib/(cache|lib|lock|log|nis|run|spool|www|yp)/

Дим, я одно не понял - ты %_localstatedir переопределишь в /var или нет ?

(In reply to comment #3)
> Дим, я одно не понял - ты %_localstatedir переопределишь в /var или нет ?

https://bugzilla.altlinux.org/show_bug.cgi?id=10382#c34
https://lists.altlinux.org/pipermail/devel/2017-October/203244.html

предложил бы какой-то аналог. Ну или в %configure поправить %_localstatedir на %_var.

А то сейчас получается так что у нас по умолчанию %configure раскрывается в --localstatedir=/var/lib \ и надо или патчить _все_ пакеты или переопределять %_localstatedir в спеке.

И то и то совсем неочевидно.

(In reply to comment #5)
> предложил бы какой-то аналог.

Есть несколько очевидных аналогов, но универсального не видно.

> Ну или в %configure поправить %_localstatedir на %_var.

Это было бы равносильно изменению значения %_localstatedir примерно в половине случаев.

> А то сейчас получается так что у нас по умолчанию %configure раскрывается в
> --localstatedir=/var/lib

Да, и это не хотелось бы менять по соображениям обратной совместимости.

> и надо или патчить _все_ пакеты

Видимо, не все, а только те, которые рассчитывают на то, что %_localstatedir раскрывается в /var.

Вообще использование макросов с красивыми длинными именами вместо фактических значений -- это зачастую лукавство, потому что поменять значения этих макросов практически нереально.

> или переопределять %_localstatedir в спеке.

Это один из вариантов, который в некоторых случаях может оказаться оптимальным.

> И то и то совсем неочевидно.

Хорошего универсального решения не видно.
Но скоро должно стать понятно, насколько криво сейчас собираются пакеты в Сизифе.

> > И то и то совсем неочевидно.
> 
> Хорошего универсального решения не видно.
> Но скоро должно стать понятно, насколько криво сейчас собираются пакеты в
> Сизифе.

Предлагаю всё-таки дополнительно проверить последствия переопределения %_localstatedir в /var, что бы понять, сколько пакетов сломается и при таком исправлении.

(In reply to comment #7)
> > > И то и то совсем неочевидно.
> > 
> > Хорошего универсального решения не видно.
> > Но скоро должно стать понятно, насколько криво сейчас собираются пакеты в
> > Сизифе.
> 
> Предлагаю всё-таки дополнительно проверить последствия переопределения
> %_localstatedir в /var

Каким образом?  В нынешней ситуации можно сделать, скажем,
grep -Elre '/var/lib/(cache|lib|lock|log|nis|run|spool|www|yp)/' %buildroot

А вот какие /var/что-то-там искать в обратном случае, неочевидно, потому список открытый.  Можно, наверное, взять все 184 каталога, которые сейчас упакованы в /var/lib/, и проверить, не станут ли они упакованы или просто упоминаться напрямую в /var/, но это будет более хрупкая проверка с точки зрения ложных срабатываний.

Можно было бы при ежедневной пересборке сравнивать содержимое предыдущего пакета с новым и в случае разницы - куда-то её записывать с информированием ментейнера.

Под содержимым имеется в виду расположение файлов.

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

(In reply to comment #9)
> Можно было бы при ежедневной пересборке сравнивать содержимое предыдущего
> пакета с новым и в случае разницы - куда-то её записывать с информированием
> ментейнера.

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

(In reply to comment #10)
> Под содержимым имеется в виду расположение файлов.
> 
> Т.е. - если у нас в одном состоянии репозитория пакет собирался с одним
> содержимым, а после изменения состояния репозитория - листинг пакета стал
> другим, то это скорее всего можно как минимум считать ошибкой, которую надо
> исправить пересборкой пакета в новой среде.

Сейчас сравнение листинга пакета в репозитории с листингом свежепересобранного пакета происходит по окончании тестовой пересборки и результат добавляется в лог.

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

А чего это баг репорт не автозакрылся?

потому что я забыл про него упомнянуть.