[devel] remove package

[devel] remove package

[Pavel Solntsev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Прошу удалить из сизифа пакет gabedit-2.18..... в связи с заменой
способа нумерации версий 2.18 => 2.1.8 (моя ошибка) новая версия 2.1.11
распознается как старая.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklI0K8ACgkQSzBBbjPd5Os5rQCgimo3z4QQz9DV5vul90FrMQz6
xdgAoJsaQci8OOO5w53SRnYTqEDiQlTy
=FNUG
-----END PGP SIGNATURE-----

Re: [devel] remove package

[Andrey Rahmatullin]

On Wed, Dec 17, 2008 at 12:13:04PM +0200, Pavel Solntsev wrote:
> Прошу удалить из сизифа 
И со всех машин, где он установлен?

> пакет gabedit-2.18..... в связи с заменой
> способа нумерации версий 2.18 => 2.1.8 (моя ошибка) новая версия 2.1.11
> распознается как старая.
Ставьте Epoch: теперь.

Re: [devel] remove package

[Mikhail Gusarov]

Twas brillig at 12:13:04 17.12.2008 UTC+02 when p_solntsev_devel@meta.ua did gyre and gimble:

 PS> Прошу удалить из сизифа пакет gabedit-2.18

Это решается с помощью Epoch, а не обращением к Духам Репозитория.

-- 

Re: [devel] remove package

[Pavel Solntsev]

Mikhail Gusarov пишет:
> Twas brillig at 12:13:04 17.12.2008 UTC+02 when p_solntsev_devel@meta.ua did gyre and gimble:
> 
>  PS> Прошу удалить из сизифа пакет gabedit-2.18
> 
> Это решается с помощью Epoch, а не обращением к Духам Репозитория.
> 
А нельзя не язвить, а подсказать человек ссылочку, объяснить :)

Re: [devel] remove package

[Mikhail Gusarov]

Twas brillig at 21:02:53 17.12.2008 UTC+02 when p_solntsev_devel@meta.ua did gyre and gimble:

 PS> А нельзя не язвить, а подсказать человек ссылочку, объяснить :)

http://www.altlinux.org/Spec#Epoch

-- 

Re: [devel] remove package

[Mikhail Gusarov]

Twas brillig at 01:05:21 18.12.2008 UTC+06 when dottedmag@altlinux.org did gyre and gimble:

 PS>> А нельзя не язвить, а подсказать человек ссылочку, объяснить :)

 MG> http://www.altlinux.org/Spec#Epoch

Ну и вообще предполагается, что майнтайнер документацию по RPM прочёл,
преждем чем начал спеки писать :-P

-- 

Re: [devel] remove package

[Pavel Solntsev]

Mikhail Gusarov пишет:
> Twas brillig at 01:05:21 18.12.2008 UTC+06 when dottedmag@altlinux.org did gyre and gimble:
> 
>  PS>> А нельзя не язвить, а подсказать человек ссылочку, объяснить :)
> 
>  MG> http://www.altlinux.org/Spec#Epoch
> 
за ссылочку спасибо, уже нашел
> Ну и вообще предполагается, что майнтайнер документацию по RPM прочёл,
> преждем чем начал спеки писать :-P
>
Если я правильно понял, вы считаете, что изначально мантейнер должен от
корки до корки прочитать всю документацию по сборке пакетов, а уж потом
собирать их. Но ведь еще Керниган и Ричии придерживались точки зрения,
что выучить язык можно  нужно непосредствено пытаясь что-либо стелать.
Это я и пытаюсь. И делаю и учюсь. Если что нитак - просто исправте.

Re: [devel] remove package

[Afanasov Dmitry]

17.12.08, Pavel Solntsev<p_solntsev_devel@meta.ua> написал(а):
> > Ну и вообще предполагается, что майнтайнер документацию по RPM прочёл,
>  > преждем чем начал спеки писать :-P
> Если я правильно понял, вы считаете, что изначально мантейнер должен от
>  корки до корки прочитать всю документацию по сборке пакетов, а уж потом
>  собирать их.
да, именно так и считается. и не только в сборке - RTFM не просто так появился.
-- 
С уважением
Афанасов Дмитрий

[devel] [JT] RTFM

[Michael Shigorin]

On Thu, Dec 18, 2008 at 12:05:06AM +0300, Afanasov Dmitry wrote:
> > > Ну и вообще предполагается, что майнтайнер документацию по
> > > RPM прочёл, преждем чем начал спеки писать :-P
> > Если я правильно понял, вы считаете, что изначально мантейнер
> > должен от корки до корки прочитать всю документацию по сборке
> > пакетов, а уж потом собирать их.
> да, именно так и считается. и не только в сборке - RTFM не
> просто так появился.

Мало кто умеет настолько сжато писать, чтоб инициатива что-либо
сделать не выветрилась по мере продирания через описание, как.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] RTFM

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

Twas brillig at 11:38:09 29.12.2008 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 MS> Мало кто умеет настолько сжато писать, чтоб инициатива что-либо
 MS> сделать не выветрилась по мере продирания через описание, как.

Да, Майк, у тебя точно не получается %)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] remove package

[Grigory Batalov]

On Wed, Dec 17, 2008 at 10:30:34PM +0200, Pavel Solntsev wrote:
> > Ну и вообще предполагается, что майнтайнер документацию по RPM прочёл,
> > преждем чем начал спеки писать :-P
> >
> Если я правильно понял, вы считаете, что изначально мантейнер должен от
> корки до корки прочитать всю документацию по сборке пакетов, а уж потом
> собирать их. Но ведь еще Керниган и Ричии придерживались точки зрения,
> что выучить язык можно  нужно непосредствено пытаясь что-либо стелать.
> Это я и пытаюсь. И делаю и учюсь. Если что нитак - просто исправте.

А у Вас есть maximum-rpm ? =)
Раздел про spec-файлы неплохо бы прочитать каждому начинающему
мэйнтейнеру, даже если потом не всё пригодится.

Re: [devel] remove package

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Thu, Dec 18, 2008 at 01:06:09AM +0600, Mikhail Gusarov wrote:
> 
> Twas brillig at 01:05:21 18.12.2008 UTC+06 when dottedmag@altlinux.org did gyre and gimble:
> 
>  PS>> А нельзя не язвить, а подсказать человек ссылочку, объяснить :)
> 
>  MG> http://www.altlinux.org/Spec#Epoch
> 
> Ну и вообще предполагается, что майнтайнер документацию по RPM прочёл,
> преждем чем начал спеки писать :-P

Думаю, нам не хватает отдельного HOWTO по RPM-версионированию. 

С примерно такими разделами:
 - общие принципы rpm-версий
  + разъяснение принципа версий ("целочисленные сегменты", а не десятичные
    числа, как в соседнем треде разъяснил at@), 
  + структура rpm-версии (Epoch-версия-релиз)
  + утилиты для сравнения версий (rpmvercmp)
  
 - версионирование пакетов в Сизифе
  + советы по преобразованию версий апстрима в rpm-версии
    (разные маргинальные случаи и известные грабли)
  + правила составления релизов (altN), в каких случаях 
    и как следует увеличивать релиз
  + правила указания релиза для бранчей (бэкпорты) 

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

-- 
Kirill Maslinsky
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] remove package

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

On Thu, Dec 18, 2008 at 10:58:02AM +0300, Kirill Maslinsky wrote:
>   + утилиты для сравнения версий (rpmvercmp)
evr!

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> 3. При загрузке системы выдается такое:
> Apr 22 22:48:41 home hotplug: Hotplug (misc.rc) start: succeeded
Дык. Скажите спасибо, что он пол-etc не сносит при этом, были
робкие попытки :)
		-- peet in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] remove package

[Alexey Morozov]

On Thursday 18 December 2008 14:31:01 Andrey Rahmatullin wrote:
> On Thu, Dec 18, 2008 at 10:58:02AM +0300, Kirill Maslinsky wrote:
> >   + утилиты для сравнения версий (rpmvercmp)
>
> evr!

И следует учесть, что именно сравнение версий в граничных условиях (не помню 
уже точно, но факт, наступали) в ALTLinux работает не так, как в остальных 
дистрибутивах. Ну, чтобы было явное указание местной специфики :-)

С уважением,
Алексей Морозов.

Re: [devel] remove package

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

On Thu, Dec 18, 2008 at 01:31:01PM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 18, 2008 at 10:58:02AM +0300, Kirill Maslinsky wrote:
> >   + утилиты для сравнения версий (rpmvercmp)
> evr!
А объясните, пожалуйста, разницу, а то мне так и не удалось найти, 
где это документировано.

PS Данное примечание следует рассматривать как ещё один аргумент 
в пользу немедленого создания HOWTO.

-- 
Kirill Maslinsky
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] remove package

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On Thu, Dec 18, 2008 at 12:33:51PM +0300, Kirill Maslinsky wrote:
> > >   + утилиты для сравнения версий (rpmvercmp)
> > evr!
> А объясните, пожалуйста, разницу
e - Epoch
ver её не учитывает.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> А в чем минусы-то наличия статических библиотек?
Большинство из них никогда, никому и нигде не нужны.
		-- mhz in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] remove package

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

On Fri, Dec 19, 2008 at 12:03:19PM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 18, 2008 at 12:33:51PM +0300, Kirill Maslinsky wrote:
> > > >   + утилиты для сравнения версий (rpmvercmp)
> > > evr!
> > А объясните, пожалуйста, разницу
> e - Epoch
> ver её не учитывает.
О, спасибо! Как просто открывался ларчик. Признайтесь, откуда Вы это
узнали? Мне правда интересно, я искал довольно долго.

-- 
Kirill Maslinsky
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] remove package

[Damir Shayhutdinov]

> On Fri, Dec 19, 2008 at 12:03:19PM +0500, Andrey Rahmatullin wrote:
>> On Thu, Dec 18, 2008 at 12:33:51PM +0300, Kirill Maslinsky wrote:
>> > > >   + утилиты для сравнения версий (rpmvercmp)
>> > > evr!
>> > А объясните, пожалуйста, разницу
>> e - Epoch
>> ver её не учитывает.
> О, спасибо! Как просто открывался ларчик. Признайтесь, откуда Вы это
> узнали? Мне правда интересно, я искал довольно долго.

rpmvercmp - от слова RPM VERsion Compare
rpmevrcmp - от слова RPM E-V-R Compare, где EVR = Epoch:Version-Release.

Суть в акронимах.

Re: [devel] remove package

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On Fri, Dec 19, 2008 at 11:19:53PM +0300, Damir Shayhutdinov wrote:
> > On Fri, Dec 19, 2008 at 12:03:19PM +0500, Andrey Rahmatullin wrote:
> >> On Thu, Dec 18, 2008 at 12:33:51PM +0300, Kirill Maslinsky wrote:
> >> > > >   + утилиты для сравнения версий (rpmvercmp)
> >> > > evr!
> >> > А объясните, пожалуйста, разницу
> >> e - Epoch
> >> ver её не учитывает.
> > О, спасибо! Как просто открывался ларчик. Признайтесь, откуда Вы это
> > узнали? Мне правда интересно, я искал довольно долго.
> 
> rpmvercmp - от слова RPM VERsion Compare
это я догадался сам

> rpmevrcmp - от слова RPM E-V-R Compare, где EVR = Epoch:Version-Release.
а вот тут сложность. дело в том, что невозможно найти (или укажите!), 
ГДЕ расшифровывается акроним EVR. Я это узнал вот только что.
Признайтесь, а Вы откуда это узнали? Ничего личного, это уже просто
исследовательский интерес о механизмах передачи тайного знания в 
сообществах разработчиков. Или это познаётся путём медитации и
просветления? ;)

> Суть в акронимах.
Предлагаю называть это СВА ;)

-- 
Kirill Maslinsky
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] remove package

[Vitaly Lipatov]

On 19 декабря 2008, Damir Shayhutdinov wrote:
...
> rpmvercmp - от слова RPM VERsion Compare
> rpmevrcmp - от слова RPM E-V-R Compare, где EVR =
> Epoch:Version-Release.
Тогда кому нужна rpmvercmp, если она неправильно работает?


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] remove package

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

On Sat, Dec 20, 2008 at 12:00:48AM +0300, Vitaly Lipatov wrote:
> On 19 декабря 2008, Damir Shayhutdinov wrote:
> ...
> > rpmvercmp - от слова RPM VERsion Compare
> > rpmevrcmp - от слова RPM E-V-R Compare, где EVR =
> > Epoch:Version-Release.
> Тогда кому нужна rpmvercmp, если она неправильно работает?

А кофе варит вообще другая утилита.  Зачем тогда нужны эти две? ;)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] remove package

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Fri, Dec 19, 2008 at 11:19:53PM +0300, Damir Shayhutdinov wrote:
> > On Fri, Dec 19, 2008 at 12:03:19PM +0500, Andrey Rahmatullin wrote:
> >> On Thu, Dec 18, 2008 at 12:33:51PM +0300, Kirill Maslinsky wrote:
> >> > > >   + утилиты для сравнения версий (rpmvercmp)
> >> > > evr!
> >> > А объясните, пожалуйста, разницу
> >> e - Epoch
> >> ver её не учитывает.
> > О, спасибо! Как просто открывался ларчик. Признайтесь, откуда Вы это
> > узнали? Мне правда интересно, я искал довольно долго.
> 
> rpmvercmp - от слова RPM VERsion Compare
> rpmevrcmp - от слова RPM E-V-R Compare, где EVR = Epoch:Version-Release.

Всё ещё проще:

rpmvercmp -- это shell-интерфейс к librpm-функции rpmvercmp().
rpmevrcmp -- это shell-интерфейс к librpm-функции rpmEVRcmp().


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] remove package

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

On Fri, Dec 19, 2008 at 11:08:10PM +0300, Kirill Maslinsky wrote:
> О, спасибо! Как просто открывался ларчик. Признайтесь, откуда Вы это
> узнали?
Из этой рассылки.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Я за альтернативы, но против неудачных альтернатив.
		-- ldv in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] HOWTO по RPM-версионированию

[Vitaly Lipatov]

On 18 декабря 2008, Kirill Maslinsky wrote:
...
> Думаю, нам не хватает отдельного HOWTO по RPM-версионированию.
Да, тоже вчера об этом думал.

> С примерно такими разделами:
>  - общие принципы rpm-версий
>   + разъяснение принципа версий ("целочисленные сегменты", а
> не десятичные числа, как в соседнем треде разъяснил at@),
Да, Алексей привёл очень хороший пример, прямо в книгу можно. И 
наверное где-то ещё могут быть такие расхождения в правилах 
нумерации.

>   + структура rpm-версии (Epoch-версия-релиз)
>   + утилиты для сравнения версий (rpmvercmp)
>
>  - версионирование пакетов в Сизифе
>   + советы по преобразованию версий апстрима в rpm-версии
>     (разные маргинальные случаи и известные грабли)
>   + правила составления релизов (altN), в каких случаях
>     и как следует увеличивать релиз
>   + правила указания релиза для бранчей (бэкпорты)
Ну это есть в полиси по бэкпортированию. Правда у меня есть к 
нему поправки :)

> Вопросы (и, что важнее, ошибки) по этой теме у начинающих
> мантейнеров возникают очень часто, думаю, не в последнюю
> очередь потому, что информация очень сильно разбросана по
> разным источникам, зачастую архивам рассылки.
Может быть соберёмся с силами, выложим на вики?


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] HOWTO по RPM-версионированию

[Vladimir V. Kamarzin]

>>>>> On 18 Dec 2008 at 13:32 "VL" == Vitaly Lipatov writes:

>>   + структура rpm-версии (Epoch-версия-релиз)
>>   + утилиты для сравнения версий (rpmvercmp)
>>
>>  - версионирование пакетов в Сизифе
>>   + советы по преобразованию версий апстрима в rpm-версии
>>     (разные маргинальные случаи и известные грабли)
>>   + правила составления релизов (altN), в каких случаях
>>     и как следует увеличивать релиз
>>   + правила указания релиза для бранчей (бэкпорты)
VL> Ну это есть в полиси по бэкпортированию. Правда у меня есть к 
VL> нему поправки :)

Какие?

-- 
vvk

Re: [devel] HOWTO по RPM-версионированию

[Vitaly Lipatov]

On 18 декабря 2008, Vladimir V. Kamarzin wrote:
> >>>>> On 18 Dec 2008 at 13:32 "VL" == Vitaly Lipatov writes:
...
> VL> Ну это есть в полиси по бэкпортированию. Правда у меня
> есть к VL> нему поправки :)
При бэкпортировании устанавливать релиз как
alt(N-1).MM.(N)
где N - это номер релиза в Сизифе, MM - это M41, M40 (обозначение 
бранча)

http://git.altlinux.org/people/lav/packages/?p=etersoft-build-utils.git;a=commitdiff;h=e83d9ca55637818cc7b60a69d733b24c5611661f

-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] HOWTO по RPM-версионированию

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

Vitaly Lipatov пишет:
> On 18 декабря 2008, Vladimir V. Kamarzin wrote:
>>>>>>> On 18 Dec 2008 at 13:32 "VL" == Vitaly Lipatov writes:
> ...
>> VL> Ну это есть в полиси по бэкпортированию. Правда у меня
>> есть к VL> нему поправки :)
> При бэкпортировании устанавливать релиз как
> alt(N-1).MM.(N)
> где N - это номер релиза в Сизифе, MM - это M41, M40 (обозначение 
> бранча)

   Тогда какой релиз должен быть у правленного (относительно 
alt(N-1).MM.(N), m`ная правка) бэкпорта: alt(N-1).MM.(N+m), или 
alt(N-1).MM.(N).(m)?

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

[devel] backports releases (was: HOWTO по RPM-версионированию)

[Michael Shigorin]

On Thu, Dec 18, 2008 at 02:17:59PM +0300, Aleksey Avdeev wrote:
> >При бэкпортировании устанавливать релиз как
> >alt(N-1).MM.(N)
> >где N - это номер релиза в Сизифе, MM - это M41, M40
> >(обозначение бранча)
> Тогда какой релиз должен быть у правленного (относительно 
> alt(N-1).MM.(N), m`ная правка) бэкпорта: alt(N-1).MM.(N+m),

Обычно такой.

> или alt(N-1).MM.(N).(m)?

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] backports releases

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

Michael Shigorin пишет:
> On Thu, Dec 18, 2008 at 02:17:59PM +0300, Aleksey Avdeev wrote:
>>> При бэкпортировании устанавливать релиз как
>>> alt(N-1).MM.(N)
>>> где N - это номер релиза в Сизифе, MM - это M41, M40
>>> (обозначение бранча)
>> Тогда какой релиз должен быть у правленного (относительно 
>> alt(N-1).MM.(N), m`ная правка) бэкпорта: alt(N-1).MM.(N+m),
> 
> Обычно такой.
> 
>> или alt(N-1).MM.(N).(m)?
> 
> Это может быть осмысленно, если заливается пакет на базе "чужого"
> в backports и есть некие соображения из опасения... короче говоря,
> сходу примеров осмысленности не припомню.

   Это не важно: такая ситуация не запрещена => возможна, и произойдёт 
рано или поздно...

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] HOWTO по RPM-версионированию

[Grigory Batalov]

On Thu, Dec 18, 2008 at 01:00:58PM +0300, Vitaly Lipatov wrote:

> > VL> Ну это есть в полиси по бэкпортированию. Правда у меня
> > есть к VL> нему поправки :)
> При бэкпортировании устанавливать релиз как
> alt(N-1).MM.(N)
> где N - это номер релиза в Сизифе, MM - это M41, M40 (обозначение 
> бранча)

А чем это лучше alt(N-1).MM.1 ... alt(N-1).MM.X ?

Re: [devel] HOWTO по RPM-версионированию

[Damir Shayhutdinov]

>> VL> Ну это есть в полиси по бэкпортированию. Правда у меня
>> есть к VL> нему поправки :)
> При бэкпортировании устанавливать релиз как
> alt(N-1).MM.(N)
> где N - это номер релиза в Сизифе, MM - это M41, M40 (обозначение
> бранча)

Определение:
дистрибутив - это Сизиф на какой-то определенный момент времени +
переложенные из Сизифа пакеты + updates..

При добавлении новой версии пакета в updates (то есть бэкпортировании)
должны быть выполнены следующие условия:

1. Пакет из updates должен замещать пакет из дистрибутива
2. Пакет из updates должен быть замещен сизифным, вышедшим позже чем
дистрибутивная версия

В терминах rpm, "x должен замещать y" означает EVRx > EVRy. (EVR =
Epoch-Version-Release).
"x должен быть замещен y" означает EVRx < EVRy.

Эти же правила можно распространить на несколько дистрибутивов,
растущий из одного и того же места  - например Desktop 4.0 и школьный
дистрибутив. Надо лишь определить "правила подчинения".

Итого, если в Сизифе на момент отделения бранча был пакет foo с версий
2.0-alt1, и он же без изменений попал в дистрибутив, тогда для
правильной работы обновлений НЕОБХОДИМО, чтобы при добавлении новой
сборки пакета foo в updates/branch, либо релиз был больше alt1, либо
версия была больше 2.0.

Простейший случай - была найдена какая-то ошибка, пакет был обновлен в
Сизифе до версии 2.0-alt2. После чего возникла необходимость
сбэкпортировать исправления из Сизифа в бранч.

Получаем два условия: релиз должен быть больше alt1, но меньше чем alt2.
Тут отлично подходит то самое правило бэкпортирования.
По правилу, релиз формируется как alt(2-1).M41.0, то есть alt1.M41.0

Правило работает.

Если в Сизифе была обновлена версия (2.1-alt1), то при бэкпортировании
надо выбирать такой релиз, который был бы меньше alt1. Правило
работает и в этом случае, то есть будет релиз alt0.M41.0 - и все
довольны.

Проблема возникает, когда в Сизифе пакет не обновился, но необходимо
обновить версию в бранче.
Допустим, в сизифе так и осталась версия 2.0-alt1. А нам необходимо
обновить пакет в бранче, не обновляя его в Сизифе.

По правилу, релиз должен быть 2.0-alt0.M41.0. Проблема в том, что этот
пакет не обновит уже установленный из бранче пакет 2.0-alt1. Придется
выкинуть правило, и сделать 2.0-alt1.M41.0. Но тогда апгрейд с бранча
до Сизифа будет сломан. К сожалению, без обновления пакета в Сизифе
этот вопрос не решить. Если между бранчем и Сизифом нету "зазора
версий", обновление будет сломано.

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

Re: [devel] HOWTO по RPM-версионированию

[Vitaly Lipatov]

On 18 декабря 2008, Damir Shayhutdinov wrote:
> Проблема возникает, когда в Сизифе пакет не обновился, но
> необходимо обновить версию в бранче.
> Допустим, в сизифе так и осталась версия 2.0-alt1. А нам
> необходимо обновить пакет в бранче, не обновляя его в Сизифе.
Мне кажется это глупой задачей. По крайней мере я так никогда 
делать не буду.

> По правилу, релиз должен быть 2.0-alt0.M41.0. Проблема в том,
alt0.M41.1

> что этот пакет не обновит уже установленный из бранче пакет
> 2.0-alt1. Придется выкинуть правило, и сделать 2.0-alt1.M41.0.
> Но тогда апгрейд с бранча до Сизифа будет сломан. К сожалению,
> без обновления пакета в Сизифе этот вопрос не решить. Если
И очень хорошо. С какой стати в бранче пакет должен быть 
обновлённее Сизиф. Простое правило; Сизиф - источник пакетов :)

> В общем, не все так просто. К счастью, такие экзотические
> случаи довольно редки и их можно решить взаимодействием
> мантейнеров.
Моё правило было для простого автомата. Вы правы, в сложной 
ситуации всегда можно внести ручные правки.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] HOWTO по RPM-версионированию

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Thu, Dec 18, 2008 at 10:44:55PM +0300, Vitaly Lipatov wrote:
> On 18 декабря 2008, Damir Shayhutdinov wrote:
> > Проблема возникает, когда в Сизифе пакет не обновился, но
> > необходимо обновить версию в бранче.
> > Допустим, в сизифе так и осталась версия 2.0-alt1. А нам
> > необходимо обновить пакет в бранче, не обновляя его в Сизифе.
> Мне кажется это глупой задачей. По крайней мере я так никогда 
> делать не буду.

Например, мантейнер пакета в Сизифе категорически против. ;)
Да, конечно, такое случается очень редко.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] HOWTO по RPM-версионированию

[Damir Shayhutdinov]

>> On 18 декабря 2008, Damir Shayhutdinov wrote:
>> > Проблема возникает, когда в Сизифе пакет не обновился, но
>> > необходимо обновить версию в бранче.
>> > Допустим, в сизифе так и осталась версия 2.0-alt1. А нам
>> > необходимо обновить пакет в бранче, не обновляя его в Сизифе.
>> Мне кажется это глупой задачей. По крайней мере я так никогда
>> делать не буду.
>
> Например, мантейнер пакета в Сизифе категорически против. ;)
> Да, конечно, такое случается очень редко.

Еще возможный пример - пакет foo зависит от сторонней библиотеки
libbar. В библиотеке libbar обнаружена некоторая особенность, которая
что-то ломает в пакете foo.
В Сизифе эту библиотеку просто обновили, и проблемы исчезли. Пакет foo
пересобирать не надо.

А в бранче по какой-то причине эту библиотеку обновлять нельзя. Тогда
надо пересобрать пакет foo без libbar в бранче. И это будет та самая
ситуация.

Re: [devel] HOWTO по RPM-версионированию

[Vladimir V. Kamarzin]

>>>>> On 19 Dec 2008 at 11:22 "DS" == Damir Shayhutdinov writes:

DS> Еще возможный пример - пакет foo зависит от сторонней библиотеки
DS> libbar. В библиотеке libbar обнаружена некоторая особенность, которая
DS> что-то ломает в пакете foo.
DS> В Сизифе эту библиотеку просто обновили, и проблемы исчезли. Пакет foo
DS> пересобирать не надо.

DS> А в бранче по какой-то причине эту библиотеку обновлять нельзя. Тогда
DS> надо пересобрать пакет foo без libbar в бранче. И это будет та самая
DS> ситуация.

Не будет, в foo просто поднимется релиз: alt0.M41.1 -> alt0.M41.2.

-- 
vvk

Re: [devel] HOWTO по RPM-версионированию

[Mikhail Gusarov]

Twas brillig at 11:36:09 19.12.2008 UTC+05 when vvk@altlinux.ru did gyre and gimble:

 VVK> Не будет, в foo просто поднимется релиз: alt0.M41.1 -> alt0.M41.2.

А если foo был переложен из Сизифа без поднятия версии?

-- 

Re: [devel] HOWTO по RPM-версионированию

[Vladimir V. Kamarzin]

>>>>> On 19 Dec 2008 at 11:37 "MG" == Mikhail Gusarov writes:

 VVK>> Не будет, в foo просто поднимется релиз: alt0.M41.1 -> alt0.M41.2.
MG> А если foo был переложен из Сизифа без поднятия версии?

Придётся поднимать версию в сизифе, не вижу что тут ещё можно придумать.

-- 
vvk

Re: [devel] HOWTO по RPM-версионированию

[Damir Shayhutdinov]

> DS> Еще возможный пример - пакет foo зависит от сторонней библиотеки
> DS> libbar. В библиотеке libbar обнаружена некоторая особенность, которая
> DS> что-то ломает в пакете foo.
> DS> В Сизифе эту библиотеку просто обновили, и проблемы исчезли. Пакет foo
> DS> пересобирать не надо.
>
> DS> А в бранче по какой-то причине эту библиотеку обновлять нельзя. Тогда
> DS> надо пересобрать пакет foo без libbar в бранче. И это будет та самая
> DS> ситуация.
>
> Не будет, в foo просто поднимется релиз: alt0.M41.1 -> alt0.M41.2.

Вова, почитай контекст. Речь идет о том, что версия и релиз в сизифе и
бранче у пакета foo совпадают (либо в Сизифе пакет не обновлялся со
времен отбранчивания, либо был переложен из Сизифа в бранч). Например
alt1.
И если ты делаешь alt0.M41.2 - то это меньше, чем alt1, и обновление
будет сломано.

[devel] [JT] источник пакетов (was: HOWTO по RPM-версионированию)

[Michael Shigorin]

On Thu, Dec 18, 2008 at 10:44:55PM +0300, Vitaly Lipatov wrote:
> > 2.0-alt1. Придется выкинуть правило, и сделать 2.0-alt1.M41.0.
> > Но тогда апгрейд с бранча до Сизифа будет сломан. К сожалению,
> > без обновления пакета в Сизифе этот вопрос не решить. Если
> И очень хорошо. С какой стати в бранче пакет должен быть 
> обновлённее Сизиф. Простое правило; Сизиф - источник пакетов :)

Зажрались вы там трафиком по своим столицам (ц)

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

-- 
Миша,
косясь на стомегабитный
канал в новом офисе

Re: [devel] HOWTO по RPM-версионированию

[Grigory Batalov]

On Thu, Dec 18, 2008 at 10:44:55PM +0300, Vitaly Lipatov wrote:
> > Проблема в том,
> > что этот пакет не обновит уже установленный из бранче пакет
> > 2.0-alt1. Придется выкинуть правило, и сделать 2.0-alt1.M41.0.
> > Но тогда апгрейд с бранча до Сизифа будет сломан. К сожалению,
> > без обновления пакета в Сизифе этот вопрос не решить. Если
> И очень хорошо. С какой стати в бранче пакет должен быть 
> обновлённее Сизиф.

Потому что на Сизиф действует ACL, а на бранчи (пока) нет.
Если выяснение отношений с мэйнтейнером затянулось (например,
он не отвечает на email), а мне в бранче нужна новая версия,
я её соберу и отправлю в incoming. А с Сизифом решим потом.

И кстати, некоторым интересно мэйнтейнить в Сизифе, а бранчи
они не замечают. Мне же, напротив, удобнее поддерживать пакет
в бранче, которым я сам пользуюсь, а в Сизиф выкладывать лишь
с оглядкой на пересобираемость.

> Простое правило; Сизиф - источник пакетов :)

Re: [devel] HOWTO по RPM-версионированию

[Led]

On Thursday, 25 December 2008 23:48:31 Grigory Batalov wrote:
> On Thu, Dec 18, 2008 at 10:44:55PM +0300, Vitaly Lipatov wrote:
> > > Проблема в том,
> > > что этот пакет не обновит уже установленный из бранче пакет
> > > 2.0-alt1. Придется выкинуть правило, и сделать 2.0-alt1.M41.0.
> > > Но тогда апгрейд с бранча до Сизифа будет сломан. К сожалению,
> > > без обновления пакета в Сизифе этот вопрос не решить. Если
> >
> > И очень хорошо. С какой стати в бранче пакет должен быть
> > обновлённее Сизиф.
>
> Потому что на Сизиф действует ACL, а на бранчи (пока) нет.
> Если выяснение отношений с мэйнтейнером затянулось (например,
> он не отвечает на email), а мне в бранче нужна новая версия,
> я её соберу и отправлю в incoming. А с Сизифом решим потом.
>
> И кстати, некоторым интересно мэйнтейнить в Сизифе, а бранчи
> они не замечают.

А зачем их "замечать", если на на них не действуют ACL и "выяснение отношений 
с мэйнтейнером" затягивается аж на ноль секунд и состоит из ноль слов?

-- 
Led

Re: [devel] acl

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

On Fri, Dec 26, 2008 at 12:02:22AM +0200, Led wrote:
> On Thursday, 25 December 2008 23:48:31 Grigory Batalov wrote:
> > On Thu, Dec 18, 2008 at 10:44:55PM +0300, Vitaly Lipatov wrote:
> > > > Проблема в том,
> > > > что этот пакет не обновит уже установленный из бранче пакет
> > > > 2.0-alt1. Придется выкинуть правило, и сделать 2.0-alt1.M41.0.
> > > > Но тогда апгрейд с бранча до Сизифа будет сломан. К сожалению,
> > > > без обновления пакета в Сизифе этот вопрос не решить. Если
> > >
> > > И очень хорошо. С какой стати в бранче пакет должен быть
> > > обновлённее Сизиф.
> >
> > Потому что на Сизиф действует ACL, а на бранчи (пока) нет.
> > Если выяснение отношений с мэйнтейнером затянулось (например,
> > он не отвечает на email), а мне в бранче нужна новая версия,
> > я её соберу и отправлю в incoming. А с Сизифом решим потом.
> >
> > И кстати, некоторым интересно мэйнтейнить в Сизифе, а бранчи
> > они не замечают.
> 
> А зачем их "замечать", если на на них не действуют ACL и "выяснение отношений 
> с мэйнтейнером" затягивается аж на ноль секунд и состоит из ноль слов?

Это два крайних подхода к acl, которые, очевидно, неудачные.

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

Когда это из планов превратится в реальность, я напишу подробнее.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] HOWTO по RPM-версионированию

[Vitaly Lipatov]

On 26 декабря 2008, Grigory Batalov wrote:
> On Thu, Dec 18, 2008 at 10:44:55PM +0300, Vitaly Lipatov wrote:
> > > Проблема в том,
> > > что этот пакет не обновит уже установленный из бранче
> > > пакет 2.0-alt1. Придется выкинуть правило, и сделать
> > > 2.0-alt1.M41.0. Но тогда апгрейд с бранча до Сизифа будет
> > > сломан. К сожалению, без обновления пакета в Сизифе этот
> > > вопрос не решить. Если
> >
> > И очень хорошо. С какой стати в бранче пакет должен быть
> > обновлённее Сизиф.
>
> Потому что на Сизиф действует ACL, а на бранчи (пока) нет.
> Если выяснение отношений с мэйнтейнером затянулось (например,
> он не отвечает на email), а мне в бранче нужна новая версия,
> я её соберу и отправлю в incoming. А с Сизифом решим потом.
На мой взгляд, это нежизнеспособный способ, провоцирующий 
путаницу, двойную работу. Работает разве что в случае, если 
пакет в Сизифе уже никому не нужен.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] HOWTO по RPM-версионированию

[Grigory Batalov]

On Fri, Dec 26, 2008 at 01:03:23AM +0300, Vitaly Lipatov wrote:

> > > И очень хорошо. С какой стати в бранче пакет должен быть
> > > обновлённее Сизиф.
> >
> > Потому что на Сизиф действует ACL, а на бранчи (пока) нет.
> > Если выяснение отношений с мэйнтейнером затянулось (например,
> > он не отвечает на email), а мне в бранче нужна новая версия,
> > я её соберу и отправлю в incoming. А с Сизифом решим потом.

> На мой взгляд, это нежизнеспособный способ, провоцирующий 
> путаницу, двойную работу. Работает разве что в случае, если 
> пакет в Сизифе уже никому не нужен.

Я его не пропагандирую, но так сложилось. Если мэйнтейнеры
сами будут обновлять пакеты и в Сизифе, и в бранче, подобные
манипуляции не понадобятся. Хотя, я как раз и указал, почему
это не всем интересно.

P.S. это был ответ на вопрос "как" в бранче может оказаться
     пакет свежее, чем в Сизифе =) 

Re: [devel] HOWTO по RPM-версионированию

[Michael Shigorin]

On Fri, Dec 26, 2008 at 01:03:23AM +0300, Vitaly Lipatov wrote:
> On 26 декабря 2008, Grigory Batalov wrote:
> > > И очень хорошо. С какой стати в бранче пакет должен быть
> > > обновлённее Сизиф.
> > Потому что на Сизиф действует ACL, а на бранчи (пока) нет.

И насколько понимаю -- не будет.  По крайней мере не в текущем виде.

> > Если выяснение отношений с мэйнтейнером затянулось (например,
> > он не отвечает на email), а мне в бранче нужна новая версия,
> > я её соберу и отправлю в incoming. А с Сизифом решим потом.
> На мой взгляд, это нежизнеспособный способ, провоцирующий 
> путаницу, двойную работу.

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

> Работает разве что в случае, если пакет в Сизифе уже никому
> не нужен.

Бывает и так, но опять же IMHO более распространена проблема
"пилу точить некогда, пилить надо".  Бишь когда непосредственно
требуемым результатом является пакет в дистрибутиве <= бранче,
а сизиф -- этакое "неизбежное зло", чтоб в следующий бранч эти
наработки не забыть донести.  При этом их регулярно забывают.

PS: не у всех сизиф есть, опять же.  Или здоровье на то.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] HOWTO по RPM-версионированию

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

Twas brillig at 11:32:25 18.12.2008 UTC+03 when lav@altlinux.ru did gyre and gimble:

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

 VL> Может быть соберёмся с силами, выложим на вики?

Хорошо бы. Лучше не отдельно, а дописать в http://www.altlinux.org/Spec

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] HOWTO по RPM-версионированию

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On Thu, Dec 18, 2008 at 02:42:40PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 11:32:25 18.12.2008 UTC+03 when lav@altlinux.ru did gyre and gimble:
> 
>  >> Вопросы (и, что важнее, ошибки) по этой теме у начинающих
>  >> мантейнеров возникают очень часто, думаю, не в последнюю
>  >> очередь потому, что информация очень сильно разбросана по
>  >> разным источникам, зачастую архивам рассылки.
> 
>  VL> Может быть соберёмся с силами, выложим на вики?
> 
> Хорошо бы. Лучше не отдельно, а дописать в http://www.altlinux.org/Spec

Нет именно что лучше отдельно. Документация для начинающих должна быть 
позадачной, я уже писал об этом с аргументацией. 
Описание спека по полям -- это справочник, который полезен только в 
том случае, если знаешь, что ищешь. Я как раз предлагаю вынести (и
развернуть) со страницы про спек информацию о том, как вести
версионирование в отдельное HOWTO, а на Spec оставить ссылки.

-- 
Kirill Maslinsky
ALT Linux Team


> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] HOWTO по RPM-версионированию

[Mikhail Gusarov]

Twas brillig at 12:37:49 18.12.2008 UTC+03 when kirill@altlinux.org did gyre and gimble:

 KM> Описание спека по полям -- это справочник, который полезен только в
 KM> том случае, если знаешь, что ищешь.

Сначала нужно зафиксировать правила, и только потом писать по ним HOWTO.

-- 

Re: [devel] HOWTO по RPM-версионированию

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On Thu, Dec 18, 2008 at 04:12:43PM +0600, Mikhail Gusarov wrote:
> 
> Twas brillig at 12:37:49 18.12.2008 UTC+03 when kirill@altlinux.org did gyre and gimble:
> 
>  KM> Описание спека по полям -- это справочник, который полезен только в
>  KM> том случае, если знаешь, что ищешь.
> 
> Сначала нужно зафиксировать правила, и только потом писать по ним HOWTO.

Согласен. Но что из обсуждаемых вопросов относится собственно к
правилам? Насколько я понимаю, это в основном разъяснения принципов
работы RPM и некоторые рекомендации по работе с апстримом.

-- 
Kirill Maslinsky
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] HOWTO по RPM-версионированию

[Mikhail Gusarov]

Twas brillig at 13:24:15 18.12.2008 UTC+03 when kirill@altlinux.org did gyre and gimble:

 >> Сначала нужно зафиксировать правила, и только потом писать по ним HOWTO.

 KM> Согласен. Но что из обсуждаемых вопросов относится собственно к
 KM> правилам? Насколько я понимаю, это в основном разъяснения принципов
 KM> работы RPM

Принцип назначения версий, смысл Epoch, версионирование
бэкпортов - это всё правила.

-- 

Re: [devel] HOWTO по RPM-версионированию

[Mikhail Gusarov]

Twas brillig at 16:30:30 18.12.2008 UTC+06 when dottedmag@altlinux.org did gyre and gimble:

 MG> Принцип назначения версий, смысл Epoch, версионирование
 MG> бэкпортов - это всё правила.

Точнее, справочный материал.

-- 

Re: [devel] HOWTO по RPM-версионированию

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]

On Thu, Dec 18, 2008 at 02:42:40PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 11:32:25 18.12.2008 UTC+03 when lav@altlinux.ru did gyre and gimble:
> 
>  >> Вопросы (и, что важнее, ошибки) по этой теме у начинающих
>  >> мантейнеров возникают очень часто, думаю, не в последнюю
>  >> очередь потому, что информация очень сильно разбросана по
>  >> разным источникам, зачастую архивам рассылки.
> 
>  VL> Может быть соберёмся с силами, выложим на вики?
> 
> Хорошо бы. Лучше не отдельно, а дописать в http://www.altlinux.org/Spec

[...]
On Thu, Dec 18, 2008 at 04:30:30PM +0600, Mikhail Gusarov wrote:
> 
> Twas brillig at 13:24:15 18.12.2008 UTC+03 when kirill@altlinux.org did gyre and gimble:
> 
>  >> Сначала нужно зафиксировать правила, и только потом писать по ним HOWTO.
> 
>  KM> Согласен. Но что из обсуждаемых вопросов относится собственно к
>  KM> правилам? Насколько я понимаю, это в основном разъяснения принципов
>  KM> работы RPM
> 
> Принцип назначения версий, смысл Epoch, версионирование
> бэкпортов - это всё правила.
> 
> Twas brillig at 16:30:30 18.12.2008 UTC+06 when dottedmag@altlinux.org did gyre and gimble:
[...]
> Точнее, справочный материал.

Я честно попытался дополнить по результатам обсуждения страницу Spec --
ну не выходит каменный цветок. Как ни крути, логика обсуждаемых задач
версионирования пакетов не укладывается в рамки справки по отдельным
полям спека. 

Как минимум, приходится вводить понятие "полная версия пакета", понимая
под этим "epoch:version-release", которые, собственно, и сравниваются 
между собой при обновлении пакетов. Задача мантейнера -- именно
обеспечивать правильный порядок этих полных версий при любом обновлении
(включая бранчи), сохраняя при этом разумный уровень детализации версии 
апстрима, позволяющий пользователю адекватно идентифицировать исходники.

Если писать это на странице Spec, то непонятно, в какое поле.
Создать раздел, объединяющий поля Version,Release,Epoch -- выпадает 
из логики справочника по полям спека, и вообще, по-хорошему, описывает
более общее понятие, относящееся к rpm-пакету в целом. 

В общем, надо, наверное, сделать отдельный справочник RPM-Versioning, 
если коллеги не согласны, что это HOWTO. А может быть правильнее
оформить это сразу как полиси? В этом случае раздел "правила нумерации
релизов" в http://www.altlinux.org/BackportsPolicy получается частным 
случаем такого общего полиси по нумерации версий.

С другой стороны, я по прежнему не уверен, что версионирование -- это
область, где нужно слишком жёстко регулировать. Важнее скорее разъяснить
основы, растолковать смысл версионирования и дать понятие о разных
стратегиях, так же, как с ведением git-репозитория.

PS Прошу прощения, что длинно, но мне этот момент представляется весьма
важным в работе по улучшению документации для разработчиков.

-- 
Kirill Maslinsky
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] HOWTO по RPM-версионированию

[Mikhail Gusarov]

Twas brillig at 23:29:47 19.12.2008 UTC+03 when kirill@altlinux.org did gyre and gimble:

 KM> Если писать это на странице Spec, то непонятно, в какое поле.

Да, не укладывается.

 KM> В общем, надо, наверное, сделать отдельный справочник RPM-Versioning, 

Да.

-- 

Re: [devel] HOWTO по RPM-версионированию

[Dmitriy M. Maslennikov]

19 декабря 2008 г. 23:29 пользователь Kirill Maslinsky
<kirill@altlinux.org> написал:
> С другой стороны, я по прежнему не уверен, что версионирование -- это
> область, где нужно слишком жёстко регулировать. Важнее скорее разъяснить
> основы, растолковать смысл версионирования и дать понятие о разных
> стратегиях, так же, как с ведением git-репозитория.
А я считаю, что нужно. С позиции пользователя мне иногда очень хочется
знать из каких исходников собран пакет. В простых случаях это не
сложно, а вот если берется что-то из систем контроля версий, то
хотелось бы иметь возможность как-то сопоставлять версию rpm с
коммитом. Ну и вообще, чтобы зоопарка не было.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] HOWTO по RPM-версионированию

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Здравствуйте Kirill Maslinsky
  В сообщении от 19 декабря 2008 Kirill Maslinsky написал(a):
> С другой стороны, я по прежнему не уверен, что версионирование
> -- это область, где нужно слишком жёстко регулировать. Важнее
> скорее разъяснить основы, растолковать смысл версионирования и
> дать понятие о разных стратегиях, так же, как с ведением
> git-репозитория.

+1

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3138 bytes --]

On Thu, Dec 18, 2008 at 10:58:02AM +0300, Kirill Maslinsky wrote:
> On Thu, Dec 18, 2008 at 01:06:09AM +0600, Mikhail Gusarov wrote:
> > 
> > Twas brillig at 01:05:21 18.12.2008 UTC+06 when dottedmag@altlinux.org did gyre and gimble:
> > 
> >  PS>> А нельзя не язвить, а подсказать человек ссылочку, объяснить :)
> > 
> >  MG> http://www.altlinux.org/Spec#Epoch
> > 
> > Ну и вообще предполагается, что майнтайнер документацию по RPM прочёл,
> > преждем чем начал спеки писать :-P
> 
> Думаю, нам не хватает отдельного HOWTO по RPM-версионированию. 
> 
> С примерно такими разделами:
>  - общие принципы rpm-версий
>   + разъяснение принципа версий ("целочисленные сегменты", а не десятичные
>     числа, как в соседнем треде разъяснил at@), 

Это нужно понимать так.  Версия есть строка; так что мы сравниваем
версии, имя две строки: str1 и str2.  Строки разбиваются на сегменты.
Далее сравнение версий происходит по сегментам, до первого неодинакового
результата.

версия := сегмент сегмент*

При исчерпании сегментов сравнение происходит как в strcmp(3),
если букву считать за сегмент (то есть подстрока меньше строки).

Сегмент может быть целочисленным или нецелочисленным.

целочисленный_сегмент := [0-9][0-9]*		(жадно)
нецелочисленный_сегемент := [^0-9][^0-9]*	(жадно)

Сравнение двух целочисленных сегментов определено естественным образом.
Сравнение целочисленного и нецелочисленного сегментов не определено (не
надо спрашивать, какая версия больше, "RC" или "33").  Сравнение двух
нецелочисленных семгенов либо определено, либо не определено.

Сравнение двух нецелочисленных сегментов по умолчанию не определено.
Тем не менее, литеральное совпадение означает равенсто нецелочисленных
сегментов.  Это позволяет считать, что "1.0" = "1.0", потому что точки
литерально совпадают (и оба целочисленных сегмента также совпадют: 1==1
и 0==0).  Равно и "alt1" = "alt1".  Но не следует, например, ставить
вопрос о сравнении версий 1.0 и 1_0 (то есть не следует надеяться, что
одна из этих версий больше другой, или же что они равны).

Сравнение нецелочисленных сегментов в некоторых случаях также
доопределяется лексикографически, но только в пределах регистра.
Так, "1a" < 1b", потому что 1==1 и 'a'<'b'.  Вместе с тем, не следует
сравнивать версии "1a" и "1.0", а также "1a" и "1B" (здесь разный
регистр букв).

>   + структура rpm-версии (Epoch-версия-релиз)

Epoch влияет следующим образом.  Нужно иметь в ввиду два обстоятельства:
1) эпоха может быть только целочисленной, так что результат сравнения
эпох всегда определён; 2) эпоха либо есть, либо её нет.

Если есть обе эпохи, то сравниваются сначала эпохи, а потом версии.
Если обеих эпох эпох нет, то сравниваются только версии.
В остальных случаях большей считается та версия, которая имеет эпоху.

Если одна из версий имеет эпоху 0, а другая версия эпохи не имеет,
то результат сравнения не определён.

>   + утилиты для сравнения версий (rpmvercmp)

rpmvercmp сравнивает только версии, без эпох.
Результат сравнений версий с эпохами при помощи rpmvercpm не определён.

rpmevrcmp использовать не следует.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2934 bytes --]

On Sat, Dec 20, 2008 at 12:00:53PM +0300, Alexey Tourbin wrote:
> > С примерно такими разделами:
> >  - общие принципы rpm-версий
> >   + разъяснение принципа версий ("целочисленные сегменты", а не десятичные
> >     числа, как в соседнем треде разъяснил at@), 
> 
> Это нужно понимать так.  Версия есть строка; так что мы сравниваем
> версии, имя две строки: str1 и str2.  Строки разбиваются на сегменты.
> Далее сравнение версий происходит по сегментам, до первого неодинакового
> результата.
> 
> версия := сегмент сегмент*
> 
> При исчерпании сегментов сравнение происходит как в strcmp(3),
> если букву считать за сегмент (то есть подстрока меньше строки).
> 
> Сегмент может быть целочисленным или нецелочисленным.
> 
> целочисленный_сегмент := [0-9][0-9]*		(жадно)
> нецелочисленный_сегемент := [^0-9][^0-9]*	(жадно)
> 
> Сравнение двух целочисленных сегментов определено естественным образом.
> Сравнение целочисленного и нецелочисленного сегментов не определено (не
> надо спрашивать, какая версия больше, "RC" или "33").  Сравнение двух
> нецелочисленных семгенов либо определено, либо не определено.
> 
> Сравнение двух нецелочисленных сегментов по умолчанию не определено.
> Тем не менее, литеральное совпадение означает равенсто нецелочисленных
> сегментов.  Это позволяет считать, что "1.0" = "1.0", потому что точки
> литерально совпадают (и оба целочисленных сегмента также совпадют: 1==1
> и 0==0).  Равно и "alt1" = "alt1".  Но не следует, например, ставить
> вопрос о сравнении версий 1.0 и 1_0 (то есть не следует надеяться, что
> одна из этих версий больше другой, или же что они равны).
> 
> Сравнение нецелочисленных сегментов в некоторых случаях также
> доопределяется лексикографически, но только в пределах регистра.
> Так, "1a" < 1b", потому что 1==1 и 'a'<'b'.  Вместе с тем, не следует
> сравнивать версии "1a" и "1.0", а также "1a" и "1B" (здесь разный
> регистр букв).
> 
> >   + структура rpm-версии (Epoch-версия-релиз)
> 
> Epoch влияет следующим образом.  Нужно иметь в ввиду два обстоятельства:
> 1) эпоха может быть только целочисленной, так что результат сравнения
> эпох всегда определён; 2) эпоха либо есть, либо её нет.
> 
> Если есть обе эпохи, то сравниваются сначала эпохи, а потом версии.
> Если обеих эпох эпох нет, то сравниваются только версии.
> В остальных случаях большей считается та версия, которая имеет эпоху.
> 
> Если одна из версий имеет эпоху 0, а другая версия эпохи не имеет,
> то результат сравнения не определён.
> 
> >   + утилиты для сравнения версий (rpmvercmp)
> 
> rpmvercmp сравнивает только версии, без эпох.

Дополнение: версия не может содержать знак "-", и релиз тоже не может
содержать знак "-".  Поэтому можно использовать rpmvercpm для сравнения
строк вида V-R.  Сначал будут сравниваться версии V.  Если они равны,
то знак "-" означает литеральное совпадение, и далее будет сравнение
релизов R.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On Sat, Dec 20, 2008 at 12:00:53PM +0300, Alexey Tourbin wrote:
> >   + структура rpm-версии (Epoch-версия-релиз)
> 
> Epoch влияет следующим образом.  Нужно иметь в ввиду два обстоятельства:
> 1) эпоха может быть только целочисленной, так что результат сравнения
> эпох всегда определён; 2) эпоха либо есть, либо её нет.
> 
> Если есть обе эпохи, то сравниваются сначала эпохи, а потом версии.
> Если обеих эпох эпох нет, то сравниваются только версии.
> В остальных случаях большей считается та версия, которая имеет эпоху.
> 
> Если одна из версий имеет эпоху 0, а другая версия эпохи не имеет,
> то результат сравнения не определён.

Дополнение: если одна версия имеет эпоху 0, а другая версия эпохи не
имеет, и при этом первая версия сама по себе больше второй, то результат
доопределяется: первая версия больше второй.  v1>v2 => 0:v1>v2.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Sat, Dec 20, 2008 at 12:35:15PM +0300, Алексей Турбин wrote:

AT> Дополнение: если одна версия имеет эпоху 0, а другая версия эпохи не
AT> имеет, и при этом первая версия сама по себе больше второй, то результат
AT> доопределяется: первая версия больше второй.  v1>v2 => 0:v1>v2.

То есть эпоха '0' это абсолютно то же самое что отсутствие эпохи?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Mikhail Gusarov]

Twas brillig at 13:06:28 20.12.2008 UTC+03 when mithraen@altlinux.ru did gyre and gimble:

 AT>> Дополнение: если одна версия имеет эпоху 0, а другая версия эпохи
 AT>> не имеет, и при этом первая версия сама по себе больше второй, то
 AT>> результат доопределяется: первая версия больше второй.  v1>v2 =>
 AT>> 0:v1>v2.

 ДС> То есть эпоха '0' это абсолютно то же самое что отсутствие эпохи?

Да, по модулю багов в утилитах.

-- 

Re: [devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Sat, Dec 20, 2008 at 01:06:28PM +0300, Денис Смирнов wrote:
> On Sat, Dec 20, 2008 at 12:35:15PM +0300, Алексей Турбин wrote:
> 
> AT> Дополнение: если одна версия имеет эпоху 0, а другая версия эпохи не
> AT> имеет, и при этом первая версия сама по себе больше второй, то результат
> AT> доопределяется: первая версия больше второй.  v1>v2 => 0:v1>v2.
> 
> То есть эпоха '0' это абсолютно то же самое что отсутствие эпохи?

Нет.

Я ранее написал, что сравнение версий не определено, если одна версия
эпоху имеет, а другая версия эпохи не имеет.

СРАВНЕНИЕ ВЕРСИЙ НЕ ОПРЕДЕЛЕНО, ЕСЛИ ОДНА ВЕРСИЯ ЭПОХУ ИМЕЕТ,
А ДРУГАЯ ВЕРСИЯ ЭПОХИ НЕ ИМЕЕТ.

Процитированное дополнение означает, что существует некоторый класс
случаев, когда сравнение двух версий, одна с эпохой, а другая без,
всё же можно безошибочно доопределить.

"Не определено" означает, что существуют особенности реализации,
которые нельзя считать интуитивно понятными.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Mikhail Gusarov]

Twas brillig at 13:39:05 20.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> СРАВНЕНИЕ ВЕРСИЙ НЕ ОПРЕДЕЛЕНО, ЕСЛИ ОДНА ВЕРСИЯ ЭПОХУ ИМЕЕТ, А
 AT> ДРУГАЯ ВЕРСИЯ ЭПОХИ НЕ ИМЕЕТ.

Ну и сполько времени ещё эта кривая особенность реализации жить будет?
Не надоело ещё тянуть за собой артефакты реализации девяносто-затёртого
года?

-- 

Re: [devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Sat, Dec 20, 2008 at 04:41:55PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 13:39:05 20.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> СРАВНЕНИЕ ВЕРСИЙ НЕ ОПРЕДЕЛЕНО, ЕСЛИ ОДНА ВЕРСИЯ ЭПОХУ ИМЕЕТ, А
>  AT> ДРУГАЯ ВЕРСИЯ ЭПОХИ НЕ ИМЕЕТ.
> 
> Ну и сполько времени ещё эта кривая особенность реализации жить будет?
> Не надоело ещё тянуть за собой артефакты реализации девяносто-затёртого
> года?

rpm-4.0 и rpm-4.4+ по-разному сравнивают некоторые версии.  Это не
кривая особенность реализации, и нельзя скаазть, что rpm-4.4 сравнивает
вресии лучше, чем rpm-4.0.  Различие нельзя объснить целиком рационально
в пользу одного из вариантов сравнения.

Мейнтенеры должны представлять себе сравнение версий так, как я ранее
написал.  Не следует направлять в репозитарий новые версии пакетов, если
сравнение старых и новых версий "не определено".

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

Здравствуйте Alexey Tourbin
  В сообщении от 20 декабря 2008 Alexey Tourbin написал(a):
> rpm-4.0 и rpm-4.4+ по-разному сравнивают некоторые версии. 
> Это не кривая особенность реализации, и нельзя скаазть, что
> rpm-4.4 сравнивает вресии лучше, чем rpm-4.0.  Различие нельзя
> объснить целиком рационально в пользу одного из вариантов
> сравнения.
>
> Мейнтенеры должны представлять себе сравнение версий так, как
> я ранее написал.  Не следует направлять в репозитарий новые
> версии пакетов, если сравнение старых и новых версий "не
> определено".
Если у нас стоит в системе rpm 4.0.4 и порядок сортировки версий 
у нас определяется её кодом, а жизнь требует что-бы понятие не 
определено не было не правильнее-ли задать порядок сортировки 
для неопределённых случаев ? Если стоит вопрос о том, что-бы 
порядок сортировки должен соответствовать rpm-4.4, то надо 
патчить rpm (и всё, что с этим связано) и на видном месте 
расписать правила сравнения версий.

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On Sat, Dec 20, 2008 at 02:15:46PM +0300, Хихин Руслан wrote:
> > rpm-4.0 и rpm-4.4+ по-разному сравнивают некоторые версии. 
> > Это не кривая особенность реализации, и нельзя скаазть, что
> > rpm-4.4 сравнивает вресии лучше, чем rpm-4.0.  Различие нельзя
> > объснить целиком рационально в пользу одного из вариантов
> > сравнения.
> >
> > Мейнтенеры должны представлять себе сравнение версий так, как
> > я ранее написал.  Не следует направлять в репозитарий новые
> > версии пакетов, если сравнение старых и новых версий "не
> > определено".
> Если у нас стоит в системе rpm 4.0.4 и порядок сортировки версий 
> у нас определяется её кодом, а жизнь требует что-бы понятие не 
> определено не было не правильнее-ли задать порядок сортировки 
> для неопределённых случаев ? Если стоит вопрос о том, что-бы 

Понятие "не опредлено" не очень плохо.  Нужно избегать того, что
"не определно", что сложно определить интуитивно понятным способом.

> порядок сортировки должен соответствовать rpm-4.4, то надо 
> патчить rpm (и всё, что с этим связано) и на видном месте 
> расписать правила сравнения версий.

Порядок сортировки это сложная тема.  Порядок должен быть
антисимметричным.  Это означает, что либо a<b, либо a>b,
а в противном случае a=b.  На "чисто версиях" реализация может
доопределить антисимметричный порядок для тех случаев, в которых
он "не определён".

С эпохами ситуация гораздо хуже: антисимметричное сравнение эпох
может нарушать интуитивно понятные представления о сравнения версий.
Эпоха просто становится "самым старшим" компонентом версии.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Mikhail Gusarov]

Twas brillig at 14:33:25 20.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> антисимметричное сравнение эпох может нарушать интуитивно понятные
 AT> представления о сравнения версий. Эпоха просто становится "самым
 AT> старшим" компонентом версии.

И чем же это плохо? Вполне себе интуитивно понятное определение. Для
тех, кто в кишках rpm не рылся.

Была эпоха никакая (нулевая), а стала первая.

-- 

Re: [devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

> Twas brillig at 14:33:25 20.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> антисимметричное сравнение эпох может нарушать интуитивно понятные
>  AT> представления о сравнения версий. Эпоха просто становится "самым
>  AT> старшим" компонентом версии.
> 
> И чем же это плохо? Вполне себе интуитивно понятное определение. Для
> тех, кто в кишках rpm не рылся.

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

# эта версия binutils поддерживает то что мне надо
Requires: binutils >= *:2.18.50

Здесь "*" импровизированно означает любую эпоху; так вот, любую
эпоху по новой схеме rpm-4.4+ указать нельзя, а достаточная эпоха
делает ненужным сравнение версий.

По старой схеме отсутствие эпохи в Requires означает любую эпоху.

> Была эпоха никакая (нулевая), а стала первая.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

Twas brillig at 14:57:33 20.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Зависимость обчно связана с версией апстримовского пакета, а не
 AT> локальной спецификой (но нельзя исключать и обратного).

Апстримовый пакет в чистом виде в репозитории не присутствует, и поэтому
такие зависимости делать не стоит:

 AT> # эта версия binutils поддерживает то что мне надо
 AT> Requires: binutils >= *:2.18.50

Это не будет работать, если epoch пришлось ввести из-за того, что по
ошибке залили пакет версии 2.170.50. Так что лучше уж не опираться на
апстримные версии, но смотреть, какой пакет какому апстриму
соответствует.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

On Sat, Dec 20, 2008 at 06:02:00PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 14:57:33 20.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> Зависимость обчно связана с версией апстримовского пакета, а не
>  AT> локальной спецификой (но нельзя исключать и обратного).
> 
> Апстримовый пакет в чистом виде в репозитории не присутствует, и поэтому
> такие зависимости делать не стоит:

Я могу быть уверен, что пакет в репозитарии с апстриповской версией
реализует функциональность в рамках апистримовской версии.  Но я *не знаю*,
какая эпоха у этого пакета в репозитарии.  А без эпохи я не могу
указать актуальную апстримовкую версию, поскольку эпоха перебивает
версию.

Получается, я должен знать больше, чем то, что уже знаю, и чего
мне как мейнтейнеру в принципе достаточно знать.  Я не могу взять
понятие апстримовской версии и поставить на неё зависимость,
мне нужно учитывать локальную специфику, которая меняется более
или менее ...

>  AT> # эта версия binutils поддерживает то что мне надо
>  AT> Requires: binutils >= *:2.18.50
> 
> Это не будет работать, если epoch пришлось ввести из-за того, что по
> ошибке залили пакет версии 2.170.50. Так что лучше уж не опираться на
> апстримные версии, но смотреть, какой пакет какому апстриму
> соответствует.

Если по ошибке залили версию, слабо связанную с апстримом, то есть
откуда её взяли, то это я не знаю.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

Twas brillig at 15:17:28 20.12.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Я могу быть уверен, что пакет в репозитарии с апстриповской версией
 AT> реализует функциональность в рамках апистримовской версии.

Нет.

 AT> Но я *не знаю*, какая эпоха у этого пакета в репозитарии.

Загляни в репозиторий.

 AT> Получается, я должен знать больше, чем то, что уже знаю, и чего
 AT> мне как мейнтейнеру в принципе достаточно знать.

"Положено знать" - вещь неспецифирированная.

 AT> Я не могу взять понятие апстримовской версии и поставить на неё
 AT> зависимость, мне нужно учитывать локальную специфику, которая
 AT> меняется более или менее ...

Именно. И особенно это присуще тем пакетам, мейнтенеры которых не просто
"перепаковывают", а творчески подходят к этому процессу. Вот, скажем,
версии перла в сизифе означают далеко не то, что в апстриме :)

 AT> Если по ошибке залили версию, слабо связанную с апстримом, то есть
 AT> откуда её взяли, то это я не знаю.

Опечатка?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] сравнение версий в rpm

[Ivan A. Melnikov]

On Saturday 20 December 2008 15:22:29 Mikhail Gusarov wrote:
> Twas brillig at 15:17:28 20.12.2008 UTC+03 when at@altlinux.ru did gyre and
> gimble:
>
>  AT> Я могу быть уверен, что пакет в репозитарии с апстриповской версией
>  AT> реализует функциональность в рамках апистримовской версии.
>
> Нет.

Имменно. 2.18.0-alt0.beta1.1 не будет реализоввывать всю функциональность в 
рамках 2.18.0.

>
>  AT> Но я *не знаю*, какая эпоха у этого пакета в репозитарии.
>
> Загляни в репозиторий.
>

Это может привести к проблемам, если из-за больших проблем в новой версии было 
решено залить предыдущую с поднятием эпохи. Тогда

Requres: binutils >= *:2.18.0

(псевдо-спек, продолжая нотацию at@) превращается в анмет (что правильно), а

Requres: binutils >= (предыдущая эпоха в сизифе):2.18.0

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

С другой стороны, это, как уже было сказано, не спасёт от 2.170.1. Технически, 
можно обойти  проблемы, указав две сторки

Requres: binutils >= *:2.18.0
Requres: binutils >= (эпоха в сизифе):2.18.0-alt1

Прада я не знаю, может ли это работать, и выглядит это страшновато...

-- 
Best regards,
Ivan A. Melnikov <iv@altlinux.org>

Re: [devel] сравнение версий в rpm

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

Здравствуйте Alexey Tourbin
  В сообщении от 20 декабря 2008 Alexey Tourbin написал(a):
> Получается, я должен знать больше, чем то, что уже знаю, и
> чего мне как мейнтейнеру в принципе достаточно знать

Вот вспоминаю в математике - "кананоческий вид" Для 
Сизифа - "кананоческий вид" это вид версии в Сизифе. 
Остальное должно обеспечиваться правилами конвертаций версий из 
всех нестандартных видов.  

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

On Sat, Dec 20, 2008 at 01:39:05PM +0300, Alexey Tourbin wrote:
> Я ранее написал, что сравнение версий не определено, если одна версия
> эпоху имеет, а другая версия эпохи не имеет.
> 
> СРАВНЕНИЕ ВЕРСИЙ НЕ ОПРЕДЕЛЕНО, ЕСЛИ ОДНА ВЕРСИЯ ЭПОХУ ИМЕЕТ,
> А ДРУГАЯ ВЕРСИЯ ЭПОХИ НЕ ИМЕЕТ.

Это неверно.  Больше та версия, у которой есть эпоха.

Есть специальный случай, когда у одной версии эпоха 0, а у другой
версии эпохи нет.  Результат сравнения версий зависит от реализации.
Нулевая эпоха либо берёт приоритет (в качестве наличия эпохи против
отсутствия эпохи у другой версии), либо нет (нулевая эпоха "не
считается").

> Процитированное дополнение означает, что существует некоторый класс
> случаев, когда сравнение двух версий, одна с эпохой, а другая без,
> всё же можно безошибочно доопределить.
> 
> "Не определено" означает, что существуют особенности реализации,
> которые нельзя считать интуитивно понятными.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

On Sat, Dec 20, 2008 at 02:08:55PM +0300, Алексей Турбин wrote:

AT> Есть специальный случай, когда у одной версии эпоха 0, а у другой
AT> версии эпохи нет.  Результат сравнения версий зависит от реализации.
AT> Нулевая эпоха либо берёт приоритет (в качестве наличия эпохи против
AT> отсутствия эпохи у другой версии), либо нет (нулевая эпоха "не
AT> считается").

IMHO стоит считать что 0-я эпоха не считается, и все что не так --
фиксить.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Sat, Dec 20, 2008 at 12:00:53PM +0300, Alexey Tourbin wrote:
> Это нужно понимать так.  Версия есть строка; так что мы сравниваем
> версии, имя две строки: str1 и str2.  Строки разбиваются на сегменты.
> Далее сравнение версий происходит по сегментам, до первого неодинакового
> результата.
> 
> версия := сегмент сегмент*
> 
> При исчерпании сегментов сравнение происходит как в strcmp(3),
> если букву считать за сегмент (то есть подстрока меньше строки).
> 
> Сегмент может быть целочисленным или нецелочисленным.
> 
> целочисленный_сегмент := [0-9][0-9]*		(жадно)
> нецелочисленный_сегемент := [^0-9][^0-9]*	(жадно)
> 
> Сравнение двух целочисленных сегментов определено естественным образом.
> Сравнение целочисленного и нецелочисленного сегментов не определено (не
> надо спрашивать, какая версия больше, "RC" или "33").  Сравнение двух
> нецелочисленных семгенов либо определено, либо не определено.
> 
> Сравнение двух нецелочисленных сегментов по умолчанию не определено.

Здесь есть конфликт двух правил.
Рассмотрим версии "1.RC" и "1.33".

"1.RC" = 1 ".RC"
"1.33" = 1 "." 33

Конфилкт появляется при сравнении второго сегмента.  С одной стороны,
подстрока меньше строки, то есть ".RC" > ".".  С другой стороны,
сравнение нецелочисленных сегментов по умолчанию не определено.

Кажается, rpm-4.0 и rpm-4.4 по-разному сравнивают эти версии.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] сравнение версий в rpm

[Vladimir V. Kamarzin]

>>>>> On 20 Dec 2008 at 14:00 "AT" == Alexey Tourbin writes:

>>   + утилиты для сравнения версий (rpmvercmp)
AT> rpmvercmp сравнивает только версии, без эпох.
AT> Результат сравнений версий с эпохами при помощи rpmvercpm не определён.
AT> rpmevrcmp использовать не следует.

А чем тогда сравнивать epoch+version+release? Городить костыли?

-- 
vvk

Re: [devel] remove package

[Michael Shigorin]

On Thu, Dec 18, 2008 at 01:06:09AM +0600, Mikhail Gusarov wrote:
>  PS>> А нельзя не язвить, а подсказать человек ссылочку, объяснить :)
>  MG> http://www.altlinux.org/Spec#Epoch

Спасибо.

> Ну и вообще предполагается, что майнтайнер документацию по RPM
> прочёл, преждем чем начал спеки писать :-P

Предполагать, что человек прочёл документацию -- обычно наивно.

В моём случае такое предположение было неверно. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] remove package

[Afanasov Dmitry]

25.12.08, Michael Shigorin<mike@osdn.org.ua> написал(а):
> On Thu, Dec 18, 2008 at 01:06:09AM +0600, Mikhail Gusarov wrote:
>  > Ну и вообще предполагается, что майнтайнер документацию по RPM
>  > прочёл, преждем чем начал спеки писать :-P
>
>
> Предполагать, что человек прочёл документацию -- обычно наивно.
но ведь это не правильно?

>  В моём случае такое предположение было неверно. :)
в моем тоже.
-- 
С уважением
Афанасов Дмитрий

Re: [devel] remove package

[Michael Shigorin]

On Thu, Dec 25, 2008 at 09:59:53PM +0300, Afanasov Dmitry wrote:
> >  > Ну и вообще предполагается, что майнтайнер документацию по
> >  > RPM прочёл, преждем чем начал спеки писать :-P
> > Предполагать, что человек прочёл документацию -- обычно наивно.
> но ведь это не правильно?

C'est la vie -- учитывать человеческие ошибки разумнее,
чем предполагать их отсутствие.

Применительно к документации -- краткая, ясная и интересная
(в терминах "зачем это мне?") вводная документация по сборке
rpm действительно была бы намного полезней предложений "пойти
почитать Max-RPM".

В качестве примера _для админа_ ("зачем мне использовать rpm?")
нередко предлагаю к прочтению вот эту статью pilot@:
http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] remove package

[Led]

On Monday, 29 December 2008 12:12:12 Michael Shigorin wrote:
> On Thu, Dec 25, 2008 at 09:59:53PM +0300, Afanasov Dmitry wrote:
> > >  > Ну и вообще предполагается, что майнтайнер документацию по
> > >  > RPM прочёл, преждем чем начал спеки писать :-P
> > >
> > > Предполагать, что человек прочёл документацию -- обычно наивно.
> >
> > но ведь это не правильно?
>
> C'est la vie -- учитывать человеческие ошибки разумнее,
> чем предполагать их отсутствие.

А предупреждать их - намного рациональнее, чем учитывать.

-- 
Led