Bug 33151 - should use /var/run/ instead of /var/lib/run/
Summary: should use /var/run/ instead of /var/lib/run/
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: cups-filters (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Anton Farygin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on: 10382
Blocks:
  Show dependency tree
 
Reported: 2017-02-20 16:44 MSK by Ivan Zakharyaschev
Modified: 2017-10-26 21:16 MSK (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Zakharyaschev 2017-02-20 16:44:22 MSK
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 .
Comment 1 Michael Shigorin 2017-08-13 19:51:51 MSK
Опять %_localstatedir кусается...
Comment 2 Dmitry V. Levin 2017-10-25 07:00:49 MSK
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)/
Comment 3 Anton Farygin 2017-10-25 08:12:18 MSK
Дим, я одно не понял - ты %_localstatedir переопределишь в /var или нет ?
Comment 4 Dmitry V. Levin 2017-10-25 08:17:12 MSK
(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
Comment 5 Anton Farygin 2017-10-25 08:28:42 MSK
предложил бы какой-то аналог. Ну или в %configure поправить %_localstatedir на %_var.

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

И то и то совсем неочевидно.
Comment 6 Dmitry V. Levin 2017-10-25 08:38:00 MSK
(In reply to comment #5)
> предложил бы какой-то аналог.

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

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

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

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

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

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

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

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

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

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

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

Хорошего универсального решения не видно.
Но скоро должно стать понятно, насколько криво сейчас собираются пакеты в Сизифе.
Comment 7 Anton Farygin 2017-10-25 08:42:03 MSK
> > И то и то совсем неочевидно.
> 
> Хорошего универсального решения не видно.
> Но скоро должно стать понятно, насколько криво сейчас собираются пакеты в
> Сизифе.

Предлагаю всё-таки дополнительно проверить последствия переопределения %_localstatedir в /var, что бы понять, сколько пакетов сломается и при таком исправлении.
Comment 8 Dmitry V. Levin 2017-10-25 09:01:48 MSK
(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/, но это будет более хрупкая проверка с точки зрения ложных срабатываний.
Comment 9 Anton Farygin 2017-10-25 09:28:19 MSK
Можно было бы при ежедневной пересборке сравнивать содержимое предыдущего пакета с новым и в случае разницы - куда-то её записывать с информированием ментейнера.
Comment 10 Anton Farygin 2017-10-25 09:32:07 MSK
Под содержимым имеется в виду расположение файлов.

Т.е. - если у нас в одном состоянии репозитория пакет собирался с одним содержимым, а после изменения состояния репозитория - листинг пакета стал другим, то это скорее всего можно как минимум считать ошибкой, которую надо исправить пересборкой пакета в новой среде.
Comment 11 Dmitry V. Levin 2017-10-25 09:37:14 MSK
(In reply to comment #9)
> Можно было бы при ежедневной пересборке сравнивать содержимое предыдущего
> пакета с новым и в случае разницы - куда-то её записывать с информированием
> ментейнера.

Если бы содержимое многих пакетов не менялось просто так в результате тестовой пересборки, в этом мог бы быть практический смысл.
Comment 12 Dmitry V. Levin 2017-10-25 09:40:38 MSK
(In reply to comment #10)
> Под содержимым имеется в виду расположение файлов.
> 
> Т.е. - если у нас в одном состоянии репозитория пакет собирался с одним
> содержимым, а после изменения состояния репозитория - листинг пакета стал
> другим, то это скорее всего можно как минимум считать ошибкой, которую надо
> исправить пересборкой пакета в новой среде.

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

Но пример с cups-filters, который мы тут обсуждаем, демонстрирует, что сравнения листинга недостаточно, нужно анализировать ещё и содержимое файлов.
Comment 13 Dmitry V. Levin 2017-10-26 21:15:34 MSK
А чего это баг репорт не автозакрылся?
Comment 14 Anton Farygin 2017-10-26 21:16:03 MSK
потому что я забыл про него упомнянуть.