Bug 33151 - should use /var/run/ instead of /var/lib/run/
: should use /var/run/ instead of /var/lib/run/
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/cups-filters)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
: 10382
:
  Show dependency tree
 
Reported: 2017-02-20 16:44 by
Modified: 2017-10-26 21:16 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2017-02-20 16:44:22
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 From 2017-08-13 19:51:51 -------
Опять %_localstatedir кусается...
------- Comment #2 From 2017-10-25 07:00:49 -------
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 From 2017-10-25 08:12:18 -------
Дим, я одно не понял - ты %_localstatedir переопределишь в /var или нет ?
------- Comment #4 From 2017-10-25 08:17:12 -------
(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 From 2017-10-25 08:28:42 -------
предложил бы какой-то аналог. Ну или в %configure поправить %_localstatedir на
%_var.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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