макрос бы, сравнивающий версии, чтоб можно было использовать в %if и с операциями >, <, >=, <= и ==
Чтоб под 3.0 собирать пакеты из Сизифа легче было.
Т.е. для M24 это использовать нельзя, а если не будет исправлено, то опять до следующего дистрибутива ждать.
Функционально это аналог %_release_tag или как там народ хотел, но более гибкий.
Эээ... я там когда-то чего-то трындел про "выявление фич" дистрибутива, тыкая пальцем в apache.spec. Возможно, это тоже имеет отношение? ...mid-air... (In reply to comment #3) > Функционально это аналог %_release_tag или как там народ хотел, но более > гибкий. Да-да-да-да-да :-)
Придумайте сам макрос, тогда и обсудим.
(In reply to comment #5) > Придумайте сам макрос, тогда и обсудим. Упаковать в отдельный пакет и без обсуждения можно ;-)
Я не вижу смысла воспринимать ALT Linux 3.0 как платформу, о которой стоит заботиться. Вот и Антон убрал #7079 blocker.
(In reply to comment #7) > Я не вижу смысла воспринимать ALT Linux 3.0 как платформу, о которой стоит > заботиться. Вот и Антон убрал #7079 blocker. А вот мне приходиться заботиться, поэтому не надо менять тему. Баг я вешал. см. https://bugzilla.altlinux.org/show_bug.cgi?id=8068
Будьте добры пример макроса и пример использования, иначе мне не понятно, чего именно вы хотите.
Типа %if %{rpmvercmp "1.1.2" >= "1.1.1z"}
Я бы даже не отказался, чтоб он в отдельном пакете был
А, теперь понятно.
%define if_ver_gt() %if "%(rpmvercmp '%1' '%2')" > "0" %define if_ver_gteq() %if "%(rpmvercmp '%1' '%2')" >= "0" %define if_ver_lt() %if "%(rpmvercmp '%2' '%1')" > "0" %define if_ver_lteq() %if "%(rpmvercmp '%2' '%1')" >= "0"
А почему rpmvercmp ? Не сразу очевидна связь между версией rpm и дистрибутивом, да и версия rpm одна может оказаться в двух дистрибутивах. Может %_distr_version ? А пример использования какой-нибудь такой: BuildRequires: libdb4-devel libmailutils-devel libpam-devel mailutils %if %_distr_version = "M24" BuildRequires: flex %elsif %_distr_version = "M30" BuildRequires: flex %else BuildRequires: flex-old %endif Если с синтаксисом if не ошибся - я это немного наобум написал.
Кстати, Compact 3.0 вот упустили, баг то ведь до выхода завели... Может не затягивать до выхода Master 3.1 ? :-)
(In reply to comment #14) > Не сразу очевидна связь между версией rpm и дистрибутивом, А зачем она?
Вариант со значением переменной типа "M30" или "M24" не слишком сильно применим. Особенно для бэкпортов, где версии софта могут сильно влиять на сборку/функционал. Например: qt4 у меня собирается без dbus при детекте ее старой версии, но если в бэкпортс выложат новый, то успешно соберется с ним и появиться соответствующий подпакет.
> > Не сразу очевидна связь между версией rpm и дистрибутивом, > А зачем она? В общем-то незачем. Потому мне rpmver... и не понравилось. >Вариант со значением переменной типа "M30" или "M24" не слишком сильно >применим. Особенно для бэкпортов, где версии софта могут сильно влиять на >сборку/функционал. Можно расширить: M31u и M31b. Ну а дальше бакпортер или апдейтер пусть список пакетов отслеживают. Или автомат придумывают, но, всё равно, наверное, это будет уже проще, когда знаешь диапазон ограничений.
(In reply to comment #18) > > > Не сразу очевидна связь между версией rpm и дистрибутивом, > > А зачем она? > В общем-то незачем. Потому мне rpmver... и не понравилось. rpmvercmp универсаден, поэтому не дает никакой связи с дистрибутивом. Ваш вариант малоприменим в бэкпортс и вообще не применим в сизифе.
Дима, а эти макросы ещё не втащил в rpm ? Я, видимо, тоже начну использовать - удобно для бэкпорта.
Какие всё-таки макросы? Я вот сомневаюсь, что сравнения <, > и пр. актуальны, а вот определить макросы, по которым можно узнать, где же пакет собирается, было бы хорошо.
(В ответ на комментарий №21) > Какие всё-таки макросы? #13 > Я вот сомневаюсь, что сравнения <, > и пр. актуальны Я приводил пример, абсолютно актуальный на тот момент. >, а вот определить макросы, > по которым можно узнать, где же пакет собирается, было бы хорошо. Это может быть система с _любым_ набором пакетов. В идеале пакет должен собираться правильно под нее. Т.е. не вижу смысла.
(В ответ на комментарий №22) ... > >, а вот определить макросы, > > по которым можно узнать, где же пакет собирается, было бы хорошо. > Это может быть система с _любым_ набором пакетов. В идеале пакет должен > собираться правильно под нее. Т.е. не вижу смысла. Я рассматриваю задачу сборки через girar, тут ничего любого нет, есть определённые версии (4.1, 5.1, sisyphus). Для моих задач мне было бы важно знать версию. Только вот altlinux-release сейчас предоставляется чем попало и в /etc/altlinux-release лежит случайный файл
(В ответ на комментарий №23) > Я рассматриваю задачу сборки через girar Я тоже >, тут ничего любого нет, есть > определённые версии (4.1, 5.1, sisyphus). Нет такой версии -- sisyphus. Это и 5.1 и 4.1 и всё вместе взятое в разные моменты времени. > Для моих задач мне было бы важно знать версию. Это понятно. Такое актуально только при сборке для кучи разных дистрибутивов.
(В ответ на комментарий №24) > (В ответ на комментарий №23) > > Я рассматриваю задачу сборки через girar > Я тоже > > >, тут ничего любого нет, есть > > определённые версии (4.1, 5.1, sisyphus). > Нет такой версии -- sisyphus. Это и 5.1 и 4.1 и всё вместе взятое в разные > моменты времени. Если вы тоже говорите про girar, то я бы предложил опираться на $ ssh git.alt acl --list sisyphus p5 5.1 5.0 4.1 4.0 > > Для моих задач мне было бы важно знать версию. > Это понятно. Такое актуально только при сборке для кучи разных дистрибутивов. Да. И, вряд ли к сожалению, ALT Linux выпустил больше чем один дистрибутив, разные версии которых требуют отличий в сборке.
(В ответ на комментарий №25) > И, вряд ли к сожалению, ALT Linux выпустил больше чем один дистрибутив, > разные версии которых требуют отличий в сборке. Вот, столько выпустил ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/backports Ну, и "ALT Linux выпустил" не особо при чем.
(В ответ на комментарий №25) > Если вы тоже говорите про girar, то я бы предложил опираться на > $ ssh git.alt acl --list А я все еще предлагаю опираться на версии пакетов. А для вас есть пакет rpm-macros-branch, в котором макрос branch_release, который на вскидку не работает и вы могли бы помочь мантейнеру его исправить ;-)
(В ответ на комментарий №26) ... > Вот, столько выпустил > ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/backports Ну я бы смотрел сюда: ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/ > Ну, и "ALT Linux выпустил" не особо при чем. Я говорю о списке различных платформ, под которые возможна сборка. (В ответ на комментарий №27) > А для вас есть пакет rpm-macros-branch, в котором макрос branch_release, > который на вскидку не работает и вы могли бы помочь мантейнеру его исправить > ;-) Я не понимаю, как это могло бы работать, так что вряд ли смогу помочь.
(В ответ на комментарий №28) > Ну я бы смотрел сюда: А вы смотрите туда, куда я ответил на ваш вопрос. > > Ну, и "ALT Linux выпустил" не особо при чем. > Я говорю о списке различных платформ, под которые возможна сборка. Неправда, т.к. в вашем списке есть "платформа" sisyphus. > > А для вас есть пакет rpm-macros-branch, в котором макрос branch_release, > > который на вскидку не работает и вы могли бы помочь мантейнеру его исправить > > ;-) > Я не понимаю, как это могло бы работать, так что вряд ли смогу помочь. Тогда отпишитесь от этой баги, пожалуйста, т.к. она получается точно не для вас.
tracked at https://bugs.launchpad.net/rpm/+bug/911031
Я, например, давно сделал себе в rpm-macros-kde-common-devel набор макросов, как в комментарии #13 и давно успешно его использую. В некоторых других пакетах, например qt4, держу отдельную копию в .spec .
А в паре с rpm-build-ubt можно, например, %if_ver_gteq %ubt_id M90C Obsolete: kde4 %endif
Расширенный набор: %if_ver_gt() %if "%(rpmvercmp '%1' '%2')" > "0" %if_ver_gteq() %if "%(rpmvercmp '%1' '%2')" >= "0" %if_ver_lt() %if "%(rpmvercmp '%2' '%1')" > "0" %if_ver_lteq() %if "%(rpmvercmp '%2' '%1')" >= "0" %if_ver_eq() %if "%(rpmvercmp '%1' '%2')" == "0" %if_ver_not_gt() %if "%(rpmvercmp '%1' '%2')" <= "0" %if_ver_not_gteq() %if "%(rpmvercmp '%1' '%2')" < "0" %if_ver_not_lt() %if "%(rpmvercmp '%2' '%1')" <= "0" %if_ver_not_lteq() %if "%(rpmvercmp '%2' '%1')" < "0" %if_ver_not_eq() %if "%(rpmvercmp '%1' '%2')" != "0"
На днях был удивлён, что в rpm spec невозможно стандартным способом без внешних утилит выполнить сравнение версий. Это же функция rpm, почему бы не обернуть её макросом ?
(In reply to Anton Farygin from comment #34) > На днях был удивлён, что в rpm spec невозможно стандартным способом без > внешних утилит выполнить сравнение версий. > > Это же функция rpm, почему бы не обернуть её макросом ? Почему-то никто этого не делал. Может быть, никому не показалось это нужно. В rpm несколько функций, которые сравнивают версии. Есть rpmvercmp, которая сравнивает именно версии, есть rpmVersionCompare, сравнивающая epoch:version-release:disttag, есть функции, сравнивающие диапазоны.
у нас я насчитал 33 пакета, использующих что-то подобное: %if "%(rpmvercmp %libsshver 0.8 )" >= "0" Да, нужно не часто, но когда нужно было бы неплохо иметь без костылей.
(Ответ для Dmitry V. Levin на комментарий #35) > Почему-то никто этого не делал. Этот-самый никто и дальше не будет делать, а я, например, делаю последние 15 лет. ;-)
(Ответ для Dmitry V. Levin на комментарий #35) > Есть rpmvercmp, которая сравнивает именно версии, > есть rpmVersionCompare, сравнивающая epoch:version-release:disttag, > есть функции, сравнивающие диапазоны. Этот же самый "никто" не против появления макросов для всех вышеперечисленных функций.
(Ответ для Dmitry V. Levin на комментарий #35) > Есть rpmvercmp, которая сравнивает именно версии, > есть rpmVersionCompare, сравнивающая epoch:version-release:disttag, Может, получится объединить?
