Насколько я понимаю, макрос %configure вызывает ./configure в частности с параметром --localstatedir=/var/lib При этом все проекты, которые я встречал, используя localstatedir, предполагают что он указывает на /var. Тут же вылезают /var/lib/lib и прочее. Нельзя ли прояснить ситуацию и указать кто прав и как лучше?
В нативном 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 для тех, кому дорога́ совместимость.
