Bug 6010

Чтоб под 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,
Может, получится объединить?