Bug 10382

В нативном RPM и в FC было:
%_localstatedir %{_prefix}/var
В MDK было:
%_localstatedir %{_var}/lib

Вероятно, у нас %_localstatedir унаследован от MDK.
Не представляю себе, что будет если его поменять.

Надо что-то делать, зачем эта несовместимость на ровном месте?
Особенно мне интересно как же мантейнеры справляются с этим?
Сколько мы с народом потратили времени, прежде чем в sane выявили все 
проблемы, связанные с несоответствием путей...
Хотя конечно в случае с sane это пошло на пользу, но пока что приходится 
добавлять к
%configure --localstatedir=%_var
что не очень красиво.
Быть может запланируем что-то "на после фриза"?

(In reply to comment #2)
> Особенно мне интересно как же мантейнеры справляются с этим?
В bluez-utils сначала было никак (#8885), потом пришёл я и сделал configure --
localstatedir=/var и %makeinstall --localstatedir=/var

Пока что я вижу что данная бага достойна быть повешенной.

1) а что сейчас в mdv?
2) наверное, можно по крайней мере грепнуть все наши спеки про %_localstatedir и
по крайней мере оценить масштабы subst? (во многих моих встречается)

Дима, держись:

rpm-4.8.0-14.fc13: %_localstatedir         %{_prefix}/var
rpm-4.6.0-6mnb2: %_localstatedir         %{_prefix}/var

(In reply to comment #6)
> Дима, держись:
> 
> rpm-4.8.0-14.fc13: %_localstatedir         %{_prefix}/var
> rpm-4.6.0-6mnb2: %_localstatedir         %{_prefix}/var

%{_prefix}/var это /usr/var?  Бред какой-то, они просто делают %_localstatedir бесмыссленным.

Раз вопрос совместимости с FC/MDK отпадает, значение %_localstatedir останется прежним.

Сам обалдел, но кстати, на подручной F10 /usr/var/ _не_ наблюдаю.

Простите что встреваю, но:

$ cat /etc/fedora-release
Fedora release 13 (Goddard)

$ rpm -q rpm
rpm-4.8.0-14.fc13.i686

$ rpm --eval %_localstatedir
/var

Это на Fedora-13-i686-Live-LXDE.iso

tracked at https://bugs.launchpad.net/rpm/+bug/911046

Я бы всё же к p7 поменял значение _localstatedir.
Может быть также заодно можно выбрать (рекомендовать) другой макрос, обозначающий каталог, где можно располагать изменяемые данные (например, задействовать _sharedstatedir). Мне кажется, всё упирается в то, какой параметр поддерживает autotools.

Кстати, в Mandriva (смотрел 2012) уже опять
_localstatedir	/var

Офигеть, насколько бага древняя.
Пытаюсь собрать ganeti на p7 и ловлю всякие /var/lib/lib и /var/lib/run

1) http://packages.altlinux.org/ganeti;
2) %define _localstatedir %_var, как вариант...

Нельзя уж так-то индифферентно.
Давайте уже примем волевое решение и поменяем.

Во всех случаях, когда используется %configure (то есть значение %_localstatedir может передаваться неявно), и значение --localstatedir реально используется при создании файлов, в пакете либо бага, либо мантейнер явно указал значение %_localstatedir.

Перечень пакетов, которые точно пострадают, наверняка можно определить.

(In reply to comment #14)
> Перечень пакетов, которые точно пострадают, наверняка можно определить.

а я починю пострадавшие пакеты.

Предварительная реализация была добавлена в rpm-build-intro:
* Вт авг 23 2016 Vitaly Lipatov <lav@altlinux.ru> 1.9.9-alt1
- add _localstatedir = /var to rpm-build-intro

(In reply to comment #15)
> (In reply to comment #14)
> > Перечень пакетов, которые точно пострадают, наверняка можно определить.
> 
> а я починю пострадавшие пакеты.

Не почините, потому что не обнаружите.

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

А ещё лучше просто оставить как есть.

> (In reply to comment #15)
> Не почините, потому что не обнаружите.

Гм? либо пакет не соберется, либо упакованный /var
изменится. Достаточно пересобрать пакеты с /var,
таких у нас 843 шт.

> А ещё лучше просто оставить как есть.

С энтропией надо бороться.
Конечно, я не призвываю прямо сейчас,
сначала желательно существенно проредить
ряды непересобирающихся пакетов
(еще один пример накопившейся энтропии).

(In reply to comment #18)
> > (In reply to comment #15)
> > Не почините, потому что не обнаружите.
> 
> Гм? либо пакет не соберется, либо упакованный /var
> изменится.

Зашьётся в исходный код и будет неправильно работать.
Узнаем лишь тогда, когда кто-нибудь не поленится отрепортить.

(In reply to comment #19)
> Зашьётся в исходный код и будет неправильно работать.
Последний случай оттестирован во всех других дистрибутивах.

(В ответ на комментарий №19)
> Зашьётся в исходный код и будет неправильно работать.
> Узнаем лишь тогда, когда кто-нибудь не поленится отрепортить.

Обычно исходный код сразу не работает у нас:
http://git.altlinux.org/gears/s/supervisor.git?p=supervisor.git;a=commitdiff;h=768f1ac6c6ddc52183bdb78f915982492dc78684

Не работало еще с 2013го года:
http://git.altlinux.org/gears/s/supervisor.git?p=supervisor.git;a=blob;f=supervisor.spec;h=27741c71807e9f1d37e1fdba286283a97d71a068;hb=665588624a3b3808f9072fab26436281aff43445

Эта бага набила оскомину.

На мой взгляд проще один раз починить что сломалось после унификации макроса %_localstatedir, чем помнить об особенности %_localstatedir при случаях:
* упаковки нового софта (постоянно спотыкаюсь на эту "особенность" альта)
* при изменении спека (ловил себя на этом)
* помнить об особенности %_localstatedir при просмотре изменений содержимого пакета после сборки

Объясните мне, почему вы считаете, что %_localstatedir лучше, чем /var?

(In reply to comment #20)
> (In reply to comment #19)
> > Зашьётся в исходный код и будет неправильно работать.
> Последний случай оттестирован во всех других дистрибутивах.

Это не так, у нас с ними разная пакетная база.

(В ответ на комментарий №22)
> Объясните мне, почему вы считаете, что %_localstatedir лучше, чем /var?

Если вопрос ко мне, то я не считаю что лучше/хуже.
Суть баги с моей колокольни: уберите лишний костыль,
отнимающий время у мейнтейнеров (время на исправление этого макроса в спеке, если берем его как пример из другого дистрибутива)
и у пользователей (баги, порождаемые различием этого макроса)

Удобство ALT в его крутой сборочной системе, но баги вроде этой все омрачают

> (In reply to comment #20)
> > (In reply to comment #19)
> > > Зашьётся в исходный код и будет неправильно работать.
> > Последний случай оттестирован во всех других дистрибутивах.
> 
> Это не так, у нас с ними разная пакетная база.

Многие пакеты из других дистров (Fedora) легко собираются на ALT,
один из пунктов добавляющий работу мейнтейнеру и проблем в пакеты - текущая бага.

(В ответ на комментарий №19)
...
> Зашьётся в исходный код и будет неправильно работать.
> Узнаем лишь тогда, когда кто-нибудь не поленится отрепортить.
если мы меняем значение с /var/lib на /var, это приведёт к тому, что пакеты станут создавать каталоги прямо в /var. Но нет никакой проблемы запретить упаковку левых каталогов в /var, как я понимаю.


Комментарий #1 от Dmitry V. Levin 2006-12-09 14:38:26 (-) [ответить]
> Не представляю себе, что будет если его поменять.
Я надеюсь, что 10 лет — достаточно большой срок, чтобы либо представить, либо не беспокоиться об этом.

(In reply to comment #22)
> Объясните мне, почему вы считаете, что %_localstatedir лучше, чем /var?

Буквально вчера столкнулся на примере libprelude.
Чтобы не писать
%configure --localstatedir=/var
Соберу ее сегодня с хаком
%define _localstatedir /var

 
> Это не так, у нас с ними разная пакетная база.
90%

(В ответ на комментарий №22)
> Объясните мне, почему вы считаете, что %_localstatedir лучше, чем /var?
_localstatedir передаётся макросом %configure в ./configure --localstatedir=
Если бы этого не было, все бы давно забыли про этот изначально дефективный localstatedir.

Так что вопрос в том, что ожидает autotools (все, использующие его) в качестве @localstatedir@.

По сути обсуждать тут нечего: есть значение, которое ожидается, и это /var, так исторически сложилось. 

Можно сделать %_statedir = /var/state, передавать его как ./configure --statedir=%_statedir. Но предварительно добавить эту поддержку в autotools.
Но это ничего не изменит, потому что все проекты вручную прибавляют lib к /var, и хранят свои каталоги в этом странном месте /var/lib, не имеющем к библиотекам никакого отношения.

И хотелось бы либо поменять исполнителя баги, либо услышать его голос.

(В ответ на комментарий №25)
> (In reply to comment #22)
> > Объясните мне, почему вы считаете, что %_localstatedir лучше, чем /var?
> 
> Буквально вчера столкнулся на примере libprelude.
> Чтобы не писать
> %configure --localstatedir=/var
> Соберу ее сегодня с хаком
> %define _localstatedir /var
Как насчёт BuildRequires: rpm-build-intro
?

(In reply to comment #27)
> Как насчёт BuildRequires: rpm-build-intro ?
я роботом, возможны конфликты с rpm-macros-*-compat.

(In reply to comment #26)
> И хотелось бы либо поменять исполнителя баги, либо услышать его голос.

Я против изменения значения макроса после ~20 лет использования.
Я понимаю, что импортировать федорные пакеты проще, если макрос будет иметь то значение, которое сейчас в федоре.
Но при этом мне очень не нравится идея ломать обратную совместимость в неопределённом множестве пакетов.
При том, что сейчас в Сизифе не пересобирается примерно 5.5% исходных пакетов, мы даже проверить толком ничего не можем.

(In reply to comment #29)
> При том, что сейчас в Сизифе не пересобирается примерно 5.5% исходных пакетов,
> мы даже проверить толком ничего не можем.

Да, конечно, эти пакеты надо починить.
Я сейчас как раз пытаюсь выявить неактивных
майнтайнеров, чтобы перевесить на @nobody
и починить роботом.

(В ответ на комментарий №29)
> Но при этом мне очень не нравится идея ломать обратную совместимость в
> неопределённом множестве пакетов.
> При том, что сейчас в Сизифе не пересобирается примерно 5.5% исходных пакетов,
> мы даже проверить толком ничего не можем.
То есть после приведения сизифа в относительный порядок ты не против возвращения к этой баге, правильно понимаю?  К сожалению, "лишние" форки и впрямь напрягают.

А известна статистика, этот макрос вообще используется?

(In reply to comment #26)

> По сути обсуждать тут нечего: есть значение, которое ожидается,
> и это /var, так исторически сложилось. 

Вопрос - где. У меня вот локально пересобранная quagga не перезапустилась сейчас. Начал разбираться и увидел, что /var/lib поменялся на /var.

Нынешнее значение %_localstatedir просуществовало с момента создания ALT и не будет изменено в обозримом будущем.

(В ответ на комментарий №34)
> Нынешнее значение %_localstatedir просуществовало с момента создания ALT и не
> будет изменено в обозримом будущем.
Альтернативное мнение в виде
%_localstatedir /var
(каковое значение ожидает ./configure из autotools)
упаковано в пакете rpm-macros-intro-conflicts для тех, кому дорога́ совместимость.