cups-filters-1.13.3-alt1.S1.x86_64 has hard-coded wrong path: # rpm -qa '*cups*' -l | xargs fgrep /var/lib/run 2>/dev/null /etc/cups/cups-browsed.conf:# DomainSocket /var/lib/run/cups/cups.sock Binary file /usr/sbin/cups-browsed matches # rpm -qf /etc/cups/cups-browsed.conf /usr/sbin/cups-browsed cups-filters-1.13.3-alt1.S1.x86_64 cups-filters-1.13.3-alt1.S1.x86_64 # Of course, there is no such as /var/lib/run -- it should be /var/run .
Опять %_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, который мы тут обсуждаем, демонстрирует, что сравнения листинга недостаточно, нужно анализировать ещё и содержимое файлов.
А чего это баг репорт не автозакрылся?
потому что я забыл про него упомнянуть.
