ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | should use /var/run/ instead of /var/lib/run/ | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Ivan Zakharyaschev <imz> |
| Component: | cups-filters | Assignee: | Anton Farygin <rider> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P3 | CC: | aen, lav, ldv, mike, rider, vseleznv |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| Bug Depends on: | 10382 | ||
| Bug Blocks: | |||
|
Description
Ivan Zakharyaschev
2017-02-20 16:44:22 MSK
Опять %_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, который мы тут обсуждаем, демонстрирует, что сравнения листинга недостаточно, нужно анализировать ещё и содержимое файлов. А чего это баг репорт не автозакрылся? потому что я забыл про него упомнянуть. |
