21905 2009-10-10 16:40:25 +0400 генерация кривых версий 2012-03-16 14:01:07 +0400 1 1 4 Development Sisyphus rpm-macros-branch unstable all Linux CLOSED FIXED P3 normal --- 1 kharpost nobody evg kharpost mike qa-sisyphus oldest_to_newest 101220 0 3981 kharpost 2009-10-10 16:40:25 +0400 Created attachment 3981 test.case Сейчас так: bash test.sh alt1.10: alt1.10 alt1.9.M50.1 alt1.9.M41.1 alt1.9.M40.1 хотелось бы видеть так: alt1.10: alt1.10 alt0.M50.10 alt0.M41.10 alt0.M40.10 101224 1 raorn 2009-10-10 19:04:19 +0400 Потрудитесь для начала прочитать Backports Policy. 101236 2 mike 2009-10-11 14:19:54 +0400 2 raorn: кажется, это недоразумение получило когда-то поддержку в etersoft-build-utils, но вообще подобная нумерация (с включением непосредственно релиза, который бэкпортится) в своё время обсуждалась для какого-то нетривиального случая и вовсе не в качестве правила. 2 kharpost: Лёша правду говорит, всё-таки стоит сперва знакомиться хотя бы при развешивании багов с тем, чтобы сослаться на основание для такого изменения (или обсудить неясность). 101241 3 kharpost 2009-10-11 15:25:37 +0400 Вы сами-то читали? http://www.altlinux.org/Spec: Release Для пакетов Sisyphus поле Release должно иметь вид в простых случаях — altN, а в сложных (см. ниже) — altN[суффикс]. Релиз пакета используется для указания номера сборки пакета при данной версии upstream-кода, N начинается с 1 для каждой новой upstream-версии и увеличивается на 1 для каждой новой сборки: 1.0-alt1 1.0-alt2 1.0-alt3 1.1-alt1 1.2-alt1 1.2-alt2 … Два особых случая — это упаковка промежуточных релизов upstream-кода и упаковка бэкпортов. [править] Промежуточные upstream-релизы При сборке промежуточных релизов upstream-кода (срезов по дате, по системе контроля версий), следует указывать информацию о срезе в поле Release: 1.0-alt1.r6543 1.0-alt1.20080101 1.0-alt1.rc1 1.0-alt1.rc2 1.0-alt1.gitda39a3ee Если система контроля версий не предоставляет линейной нумерации коммитов, то с каждым новым срезом нужно увеличивать номер релиза: 1.0-alt1.hg.da39a3ee 1.0-alt2.hg.0d3255bf 1.0-alt3.hg.fef95601 Для линеаризации номера версии в git можно использовать git describe: 1.0-alt1.git1.5.4-1-g18208b2 1.0-alt1.git1.5.4-2-93f1595a 1.0-alt1.git1.5.4-3-8be800af При первой сборке финального upstream-релиза следует поднять номер релиза пакета: 1.0-alt1.gitda39a3ee 1.0-alt2.gitd06f1866 1.0-alt3 Использовать релиз alt0 запрещено — пакет с таким релизом, попав в репозиторий, порождает проблемы с бэкпортами. http://www.altlinux.org/BackportsPolicy Правила нумерации релизов Релизы нумеруются следующим образом: ADAPTED_RELEASE.DISTRO.BACKPORT_RELEASE. Таким образом, полное наименование пакета будет таким: %name-%version-ADAPTED_RELEASE.DISTRO.BACKPORT_RELEASE К примеру, первый бэкпорт пакета foo-1.0-alt1 на branch/4.0 будет выглядеть как foo-1.0-alt0.M40.1. Где: ADAPTED_RELEASE — релиз, выбраный таким образом, что ORIG_RELEASE <= ADAPTED_RELEASE < SISYPHUS_RELEASE. Рекомендуемое значение — SISYPHUS_RELEASE - 1. ORIG_RELEASE — строка, описывающая релиз пакета, из которого «растёт» данная ветка (который был переложен в бранч из Сизифа); SISYPHUS_RELEASE — релиз пакета в Сизифе, на базе которого делался backport пакет; BACKPORT_RELEASE — номер релиза пакета внутри репозитория backports. Нумерация начинается с 1. DISTRO — дистрибутив, на который осуществляется портирование. При обновлении в бэкпортах до новой версии (%version) пакета, BACKPORTS_RELEASE сбрасывается в 1 и ORIG_RELEASE устанавливается в alt0. Такая схема версионирования выбрана потому, что новая версия пакета, собираемого в backports, должна иметь номер релиза меньший, чем та же версия в Сизифе, но при этом не меньший, чем та же версия в backports для предыдущих серий. Ещё была ссылка -- не нашёл -- там показаны были релизы в бэкпорты с указанием подсборок Таким образом, макрос противоречит документации. 101242 4 3982 kharpost 2009-10-11 15:33:46 +0400 Created attachment 3982 Добавлена сортировка 101243 5 solo 2009-10-11 17:00:48 +0400 См. http://www.altlinux.org/BackportsPolicy#.D0.9F.D1.80.D0.B0.D0.B2.D0.B8.D0.BB.D0.B0_.D0.BD.D1.83.D0.BC.D0.B5.D1.80.D0.B0.D1.86.D0.B8.D0.B8_.D1.80.D0.B5.D0.BB.D0.B8.D0.B7.D0.BE.D0.B2 <cite>Если необходимо предотвратить возможность обновления с релиза вида alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не alt7.<cite> Именно эту задачу и выполняет данный макрос, т. к. я стараюсь синхронно обновлять пакеты в Сизифе и бранчах (когда нет противопоказаний к бэкпортированию). По примерам: (В ответ на комментарий №0) > bash test.sh > alt1.10: alt1.10 alt1.9.M50.1 alt1.9.M41.1 alt1.9.M40.1 При этом, для apt/rpm: alt1.10 > alt1.9.M50.1 > alt1.9.M41.1 > alt1.9.M40.1 Тогда для alt1.11 (который > alt1.10) будет так: alt1.11: alt1.11 > alt1.10.M50.1 > alt1.10.M41.1 > alt1.10.M40.1 И alt1.10.M50.1 < alt1.10 => новый пакет не будет заменён старым (пусть и из Сизифа). (В ответ на комментарий №0) > хотелось бы видеть так: > alt1.10: alt1.10 alt0.M50.10 alt0.M41.10 alt0.M40.10 Тогда для alt1.11 (который > alt1.10) будет так: alt1.11: alt1.11 > alt0.M50.11 > alt0.M41.11 > alt0.M40.11 Но: alt0.M50.11 < alt1.10 => более новый пакет будет заменён на старый (но из Сизифа). 101244 6 kharpost 2009-10-11 17:13:32 +0400 > > Тогда для alt1.11 (который > alt1.10) будет так: > > alt1.11: alt1.11 > alt0.M50.11 > alt0.M41.11 > alt0.M40.11 > > Но: alt0.M50.11 < alt1.10 => более новый пакет будет заменён на старый (но из > Сизифа). Если переходишь на сизиф -- то будет заменён (но не на старую), а если не переходишь -- почему он должен заменится? По правилам у нас в сизифе не может быть более старой версии. И зачем тогда бесполезная .1 после М*? 101245 7 raorn 2009-10-11 17:27:37 +0400 Рекомендую сначала думать, а потом писать комментарии. Может тогда и писать ничего не придётся. Наличие в сизифе пакета с release равным alt1.10 не исключает присутствие в бранче пакета с release равным, например, alt1.4 и пакет с release alt0.M*.1 его не заменит. "Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч, без заливки ненужного хлама во все репозитарии. 101248 8 kharpost 2009-10-11 17:51:48 +0400 (В ответ на комментарий №7) > Рекомендую сначала думать, а потом писать комментарии. Может тогда и писать > ничего не придётся. Перестаньте хамить. > Наличие в сизифе пакета с release равным alt1.10 не исключает присутствие в > бранче пакета с release равным, например, alt1.4 и пакет с release alt0.M*.1 > его не заменит. Link? > > "Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч, > без заливки ненужного хлама во все репозитарии. Тогда вы вероятно знаете как: эту единицу поднять с помощью данного макроса? 101255 9 solo 2009-10-11 19:48:27 +0400 (В ответ на комментарий №8) > (В ответ на комментарий №7) ... > > Наличие в сизифе пакета с release равным alt1.10 не исключает присутствие в > > бранче пакета с release равным, например, alt1.4 и пакет с release alt0.M*.1 > > его не заменит. > Link? Сходу не укажу, но данная ситуация типична, т. к. основа бранча -- срез Сизифа в некоторый момент времени. Т. е.: 1. В Сизифе -- altN.M 2. Отпочковывается бранч => altN.M переезжает туда. 3. В Сизифе пакет обновился до altN.M+1 4. Пробуем поместить пикет в бранч: Текущий алгоритм (в макросе) сгенирирует altN.M.<бранч>.1, который спокойно обновит пакет в бранче. Твой -- altN-1.<бранч>.M... И как собираешся вытеснять altN.M? > > > > "Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч, > > без заливки ненужного хлама во все репозитарии. > Тогда вы вероятно знаете как: эту единицу поднять с помощью данного макроса? Определив макрос %branch_release_num... 101257 10 solo 2009-10-11 19:52:02 +0400 (В ответ на комментарий №3) ... > > Ещё была ссылка -- не нашёл -- там показаны были релизы в бэкпорты с указанием > подсборок > Таким образом, макрос противоречит документации. Цитирую ещё раз http://www.altlinux.org/BackportsPolicy: Если необходимо предотвратить возможность обновления с релиза вида alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не alt7. 101262 11 kharpost 2009-10-11 20:24:01 +0400 (В ответ на комментарий №9) > Сходу не укажу, но данная ситуация типична, т. к. основа бранча -- срез > Сизифа в некоторый момент времени. Т. е.: > > 1. В Сизифе -- altN.M > > 2. Отпочковывается бранч => altN.M переезжает туда. > > 3. В Сизифе пакет обновился до altN.M+1 > > 4. Пробуем поместить пикет в бранч: Текущий алгоритм (в макросе) сгенирирует > altN.M.<бранч>.1, который спокойно обновит пакет в бранче. Твой -- > altN-1.<бранч>.M... И как собираешся вытеснять altN.M? > Очень просто: altN+1. ... Или есть ограничения на максимальный N? > > > > > > "Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч, > > > без заливки ненужного хлама во все репозитарии. > > Тогда вы вероятно знаете как: эту единицу поднять с помощью данного макроса? > > Определив макрос %branch_release_num... тогда другое дело: это меня устраивает. Только наверное удобнее это оформить вторым параметром. 101264 12 solo 2009-10-11 21:12:48 +0400 (В ответ на комментарий №11) > (В ответ на комментарий №9) > > Сходу не укажу, но данная ситуация типична, т. к. основа бранча -- срез > > Сизифа в некоторый момент времени. Т. е.: > > > > 1. В Сизифе -- altN.M > > > > 2. Отпочковывается бранч => altN.M переезжает туда. > > > > 3. В Сизифе пакет обновился до altN.M+1 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > 4. Пробуем поместить пикет в бранч: Текущий алгоритм (в макросе) сгенирирует > > altN.M.<бранч>.1, который спокойно обновит пакет в бранче. Твой -- > > altN-1.<бранч>.M... И как собираешся вытеснять altN.M? > > > Очень просто: altN+1. ... > Или есть ограничения на максимальный N? Нет. Но по условию задачи -- в Сизифе altN.M+1 (см. выше), и этот altN.M+1 < altN+1... Или собираешся требовать _обязательного_ роста N? Он у нас не всегда возможен. В частности см. http://www.altlinux.org/NMU: Если пакет обновлял не мантейнер, то увеличивать N он права не имеет, но может добавить/увеличить M. А это -- как раз тот случай, который я описал выше. > > > > > > > > "Бесполезная .1 после .M*" нужна для сборки нового пакета только в этот бранч, > > > > без заливки ненужного хлама во все репозитарии. > > > Тогда вы вероятно знаете как: эту единицу поднять с помощью данного макроса? > > > > Определив макрос %branch_release_num... > тогда другое дело: это меня устраивает. > Только наверное удобнее это оформить вторым параметром. Для скрипта branch_release это и есть второй параметр. Для макроса же -- патчи приветствуются. 101265 13 kharpost 2009-10-11 21:38:05 +0400 > Нет. Но по условию задачи -- в Сизифе altN.M+1 (см. выше), и этот altN.M+1 < > altN+1... Или собираешся требовать _обязательного_ роста N? Он у нас не всегда > возможен. > > В частности см. http://www.altlinux.org/NMU: Если пакет обновлял не > мантейнер, то увеличивать N он права не имеет, но может добавить/увеличить M. А > это -- как раз тот случай, который я описал выше. > Если я правильно понимаю N -- номер сборки в альте. M -- номер подсборки. Номер сборки правильнее менять при каждой сборке (обновлении пакета), а M нужно увеличивать, когда эта сборка не прошла и требуется повторная сборка. такого подхода требует www.altlinux.org/Spec. 101266 14 solo 2009-10-11 22:10:33 +0400 (В ответ на комментарий №13) > > Нет. Но по условию задачи -- в Сизифе altN.M+1 (см. выше), и этот altN.M+1 < > > altN+1... Или собираешся требовать _обязательного_ роста N? Он у нас не всегда > > возможен. > > > > В частности см. http://www.altlinux.org/NMU: Если пакет обновлял не ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > мантейнер, то увеличивать N он права не имеет, но может добавить/увеличить M. А > > это -- как раз тот случай, который я описал выше. > > > Если я правильно понимаю N -- номер сборки в альте. M -- номер подсборки. Номер > сборки правильнее менять при каждой сборке (обновлении пакета), а M нужно > увеличивать, когда эта сборка не прошла и требуется повторная сборка. > такого подхода требует www.altlinux.org/Spec. Нет, это далеко не так. См. например ссылку выше... 1. В случаи, если сборка не прошла -- для исправленной повышать релиз вообще не требуется: она зальётся и со старым релизом. 2. _Технически_ повышать релиз _необходимо_ только в одном случаи -- когда пакет со старым релизом в репозитории _уже_ есть: система не даст залить пакет, если его релиз <= релизу существующего. 3. Есть достаточно много случаев применения многоцифровых релизов. На вскидку: a) NMU (см. выделенную ссылку); b) пересборка роботом; c) нумерация срезов (в частности то, что ты цитировал); d) удобство мантейнера (например, я так нумерую тестовые версии); e) пр.; 101961 15 3999 kharpost 2009-10-22 12:06:57 +0400 Created attachment 3999 Добавлена сортировка и сравнение по правилам rpm 101963 16 kharpost 2009-10-22 12:27:02 +0400 Макрос генерирует правильно: bash test.sh alt1.10: alt1.10=alt1.10>alt1.9.M50.2>alt1.9.M50.1>alt1.9.M41.2>alt1.9.M41.1>alt1.9.M40.2>alt1.9.M40.1 alt1.p3: alt1.p3=alt1.p3>alt1.p2.M50.2>alt1.p2.M50.1>alt1.p2.M41.2>alt1.p2.M41.1>alt1.p2.M40.2>alt1.p2.M40.1 alt1.9: alt1.9=alt1.9>alt1.8.M50.2>alt1.8.M50.1>alt1.8.M41.2>alt1.8.M41.1>alt1.8.M40.2>alt1.8.M40.1 alt1.9.1: alt1.9.1=alt1.9.1>alt1.9.0.M50.2>alt1.9.0.M50.1>alt1.9.0.M41.2>alt1.9.0.M41.1>alt1.9.0.M40.2>alt1.9.0.M40.1 alt1.10.1: alt1.10.1=alt1.10.1>alt1.10.0.M50.2>alt1.10.0.M50.1>alt1.10.0.M41.2>alt1.10.0.M41.1>alt1.10.0.M40.2>alt1.10.0.M40.1 alt1.svn20090812: alt1.svn20090812=alt1.svn20090812>alt1.svn20090811.M50.2>alt1.svn20090811.M50.1>alt1.svn20090811.M41.2>alt1.svn20090811.M41.1>alt1.svn20090811.M40.2>alt1.svn20090811.M40.1 alt1.svn20090812.10: alt1.svn20090812.10=alt1.svn20090812.10>alt1.svn20090812.9.M50.2>alt1.svn20090812.9.M50.1>alt1.svn20090812.9.M41.2>alt1.svn20090812.9.M41.1>alt1.svn20090812.9.M40.2>alt1.svn20090812.9.M40.1 alt1.svn20090812.11: alt1.svn20090812.11=alt1.svn20090812.11>alt1.svn20090812.10.M50.2>alt1.svn20090812.10.M50.1>alt1.svn20090812.10.M41.2>alt1.svn20090812.10.M41.1>alt1.svn20090812.10.M40.2>alt1.svn20090812.10.M40.1 alt1.svn20090812.11=alt1.svn20090812.11>alt1.svn20090812.10.M50.2>alt1.svn20090812.10.M50.1>alt1.svn20090812.10.M41.2>alt1.svn20090812.10.M41.1>alt1.svn20090812.10.M40.2>alt1.svn20090812.10.M40.1>alt1.svn20090812.10=alt1.svn20090812.10>alt1.svn20090812.9.M50.2>alt1.svn20090812.9.M50.1>alt1.svn20090812.9.M41.2>alt1.svn20090812.9.M41.1>alt1.svn20090812.9.M40.2>alt1.svn20090812.9.M40.1>alt1.svn20090812=alt1.svn20090812>alt1.svn20090811.M50.2>alt1.svn20090811.M50.1>alt1.svn20090811.M41.2>alt1.svn20090811.M41.1>alt1.svn20090811.M40.2>alt1.svn20090811.M40.1>alt1.p3=alt1.p3>alt1.p2.M50.2>alt1.p2.M50.1>alt1.p2.M41.2>alt1.p2.M41.1>alt1.p2.M40.2>alt1.p2.M40.1>alt1.10.1=alt1.10.1>alt1.10.0.M50.2>alt1.10.0.M50.1>alt1.10.0.M41.2>alt1.10.0.M41.1>alt1.10.0.M40.2>alt1.10.0.M40.1>alt1.10=alt1.10>alt1.9.M50.2>alt1.9.M50.1>alt1.9.M41.2>alt1.9.M41.1>alt1.9.M40.2>alt1.9.M40.1>alt1.9.1=alt1.9.1>alt1.9.0.M50.2>alt1.9.0.M50.1>alt1.9.0.M41.2>alt1.9.0.M41.1>alt1.9.0.M40.2>alt1.9.0.M40.1>alt1.9=alt1.9>alt1.8.M50.2>alt1.8.M50.1>alt1.8.M41.2>alt1.8.M41.1>alt1.8.M40.2>alt1.8.M40.1 alt1.10>alt0.10.M50.2>alt0.10.M50.1>alt0.10.M41.2>alt0.10.M41.1>alt0.10.M40.2>alt0.10.M40.1 Очень смущает насильственное понижение релиза. Единственное, что можно предложить, так это не обязательное введение нового поля alt1.10.1>alt1.10.0.M50.2>alt1.10.0.M50.1>alt1.10.0.M41.2>alt1.10.0.M41.1>alt1.10.0.M40.2>alt1.10.0.M40.1 Это уже выглядит много логичнее 101964 17 4000 kharpost 2009-10-22 12:28:13 +0400 Created attachment 4000 Добавлена сортировка и сравнение по правилам rpm 102328 18 solo 2009-10-29 15:52:59 +0300 (В ответ на комментарий №16) > Макрос генерирует правильно: ... > Очень смущает насильственное понижение релиза. Единственное, что можно > предложить, так это не обязательное введение нового поля > alt1.10.1>alt1.10.0.M50.2>alt1.10.0.M50.1>alt1.10.0.M41.2>alt1.10.0.M41.1>alt1.10.0.M40.2>alt1.10.0.M40.1 > Это уже выглядит много логичнее Но требует дополнительных ограничений на формат релиза... Не думаю,что оно (ограничение) обосновано. PS: Багу закрываю. 3981 2009-10-10 16:40:25 +0400 2009-10-10 16:40:25 +0400 test.case test.sh application/x-shellscript 190 kharpost IyEvYmluL2Jhc2gKCmZvciByZWwgaW4gYWx0MS4xMDsgZG8KICBlY2hvIC1uICIkcmVsOiAiCiAg Zm9yIGJyIGluICIiIE01MCBNNDEgTTQwOyBkbwogICAgZWNobyAtbiAiJChycG0gLS1kZWZpbmUg ImJyYW5jaF9zd2l0Y2ggXCIkYnJcIiIgLS1ldmFsICIlYnJhbmNoX3JlbGVhc2UgJHJlbCIpICIK ICBkb25lCiAgZWNobwpkb25lCg== 3982 2009-10-11 15:33:46 +0400 2009-10-11 15:33:46 +0400 Добавлена сортировка test.sh text/plain 345 kharpost IyEvYmluL2Jhc2gKCnRtcD0iJChta3RlbXAgdG1wLlhYWCkiCmZvciByZWwgaW4gYWx0MS4xMCBh bHQxLnAzIGFsdDEuOSBhbHQxLjEwLjEgYWx0MS5zdm4yMDA5MDgxMiBhbHQxLnN2bjIwMDkwODEy LjEwIGFsdDEuc3ZuMjAwOTA4MTIuMTE7IGRvCiAgZWNobyAtbiAiJHJlbDogIgogIDo+IiR0bXAi CiAgZm9yIGJyIGluICIiIE01MCBNNDEgTTQwOyBkbwogICAgcnBtIC0tZGVmaW5lICJicmFuY2hf c3dpdGNoIFwiJGJyXCIiIC0tZXZhbCAiJWJyYW5jaF9yZWxlYXNlICRyZWwiID4+IiR0bXAiCiAg ZG9uZQogIHNvcnQgIiR0bXAiIHwgc2VkICc6YTtOO3MvXG4vIC87dGEnCmRvbmUKcm0gLWYgIiR0 bXAi 3999 2009-10-22 12:06:57 +0400 2009-10-22 12:28:13 +0400 Добавлена сортировка и сравнение по правилам rpm test.sh text/plain 2222 kharpost IyEvYmluL2Jhc2gKCnJwbXNvcnQgKCkgewpsb2NhbCB1bnNvcnRlZCBzdHIxIHN0cjIgdG1wIHRt cG8gdG1wZSBsaW5lcyBpCnRtcG89IiQobWt0ZW1wIHRtcC5YWFgpIgp0bXBlPSIkKG1rdGVtcCB0 bXAuWFhYKSIKdW5zb3J0ZWQ9MQp3aGlsZSAoKHVuc29ydGVkKSk7IGRvCiAgdW5zb3J0ZWQ9MAog IHN0cjI9CiAgbGluZXM9IiQoc2VkIC1uICIkPSIgIiQxIikiCiAgZm9yICgoaT0xOyBpPD1saW5l czsgaSsrKSk7IGRvCiAgICBzdHIxPSIkKHNlZCAiJGkiJyFkJyAiJDEiKSIKICAgIFsgLXogIiRz dHIxIiBdICYmIGNvbnRpbnVlCiAgICBpZiBbIC16ICIkc3RyMiIgXTsgdGhlbgogICAgICBzdHIy PSIkc3RyMSIKICAgICAgY29udGludWUKICAgIGZpCiAgICBpZiBbICIkKHJwbWV2cmNtcCAiJHN0 cjEiICIkc3RyMiIpIiAtZ3QgMCBdOyB0aGVuCiAgICAgIHVuc29ydGVkPTEKIyAgICAgICBlY2hv ICJ0bXBvIgogICAgICBlY2hvICIkc3RyMSIgPj4gIiR0bXBvIgogICAgZWxzZQojICAgICAgIGVj aG8gInRtcG8iCiAgICAgIGVjaG8gIiRzdHIyIiA+PiAiJHRtcG8iCiAgICAgIHN0cjI9IiRzdHIx IgogICAgZmkKIyAgICAgICBlY2hvICJ0bXBlIgogICAgZWNobyAiJHN0cjIiID4gIiR0bXBlIgog IGRvbmUKICBlY2hvICIkc3RyMiIgPj4gIiR0bXBvIgogIGNhdCAiJHRtcG8iID4iJDEiCiAgOj4i JHRtcG8iCmRvbmUKcm0gLWYgIiR0bXBvIiAiJHRtcGUiCn0KCnBybiAoKSB7CiAgbG9jYWwgbGlu ZXMgaSBzdHIxIHN0cjIgY29uIHRtcAojICAgZWNobyAtbiAiJChzZWQgJzEhZCcgIiQxIikiCiAg bGluZXM9IiQoc2VkIC1uICIkPSIgIiQxIikiCiAgZm9yICgoaT0xOyBpPD1saW5lczsgaSsrKSk7 IGRvCiAgICBzdHIxPSIkKHNlZCAiJGkiJyFkJyAiJDEiKSIKICAgIFsgLXogIiRzdHIxIiBdICYm IGNvbnRpbnVlCiAgICBpZiBbIC16ICIkc3RyMiIgXTsgdGhlbgogICAgICBzdHIyPSIkc3RyMSIK ICAgICAgY29udGludWUKICAgIGZpCiAgICBlY2hvIC1uICIkc3RyMiIKICAgIGNvbj0iJChycG1l dnJjbXAgIiRzdHIxIiAiJHN0cjIiKSIKICAgIHRtcD0iPj08IgogICAgZWNobyAtbiAiJHt0bXA6 Y29uKzE6MX0iCiMgICAgIFsgIiRjb24iIC1sdCAwIF0gJiYgZWNobyAtbiAiPiIKIyAgICAgWyAi JGNvbiIgLWVxIDAgXSAmJiBlY2hvIC1uICI9IgojICAgICBbICIkY29uIiAtZ3QgMCBdICYmIGVj aG8gLW4gIjwiCiAgICBzdHIyPSIkc3RyMSIKICBkb25lCiAgZWNobyAiJHN0cjIiCn0KCnRtcD0i JChta3RlbXAgdG1wLlhYWCkiCnRtcGE9IiQobWt0ZW1wIHRtcC5YWFgpIgp0bXBvPSIkKG1rdGVt cCB0bXAuWFhYKSIKZm9yIHJlbCBpbiBhbHQxLjEwIGFsdDEucDMgYWx0MS45IGFsdDEuOS4xIGFs dDEuMTAuMSBhbHQxLnN2bjIwMDkwODEyIGFsdDEuc3ZuMjAwOTA4MTIuMTAgYWx0MS5zdm4yMDA5 MDgxMi4xMTsgZG8KICBlY2hvIC1uICIkcmVsOiAiCiAgOj4iJHRtcCIKICBmb3IgYnIgaW4gIiIg TTUwIE00MSBNNDA7IGRvCiAgICBmb3IgKChicmFuY2hfcmVsZWFzZV9udW09MTticmFuY2hfcmVs ZWFzZV9udW08PTI7YnJhbmNoX3JlbGVhc2VfbnVtKyspKTsgZG8KICAgICAgcnBtIC0tZGVmaW5l ICJicmFuY2hfcmVsZWFzZV9udW0gXCIkYnJhbmNoX3JlbGVhc2VfbnVtXCIiIC0tZGVmaW5lICJi cmFuY2hfc3dpdGNoIFwiJGJyXCIiIC0tZXZhbCAiJWJyYW5jaF9yZWxlYXNlICRyZWwiID4+IiR0 bXAiCiAgICBkb25lCiAgZG9uZQogIHJwbXNvcnQgIiR0bXAiCiAgcHJuICIkdG1wIgogIGVjaG8K IyBzZWQgJzphO047cy9cbi8gLzt0YScgIiR0bXAiCiAgY2F0ICIkdG1wYSIgIiR0bXAiID4gIiR0 bXBvIgogIGNwIC1mICIkdG1wbyIgIiR0bXBhIgpkb25lCgpycG1zb3J0ICIkdG1wbyIKcHJuICIk dG1wbyIKZWNobwoKY2F0IDw8RU9GID4iJHRtcCIKYWx0MS4xMAphbHQwLjEwLk01MC4xCmFsdDAu MTAuTTQxLjEKYWx0MC4xMC5NNDAuMQphbHQwLjEwLk01MC4yCmFsdDAuMTAuTTQxLjIKYWx0MC4x MC5NNDAuMgoKRU9GCnJwbXNvcnQgIiR0bXAiCnBybiAiJHRtcCIKZWNobwoKcm0gLWYgIiR0bXAi ICIkdG1wbyIgIiR0bXBhIgpleGl0CgpmaWxlIC92YXIvd3d3L2h0bWwvbGlnaHRzcXVpZC91c2Vy X21vbnRoLmNnaSBmcm9tIGluc3RhbGwgb2YgbGlnaHRzcXVpZC1hZG1pbi0xLjguMC4xLWFsdDIu MTEgY29uZmxpY3RzIHdpdGggZmlsZSBmcm9tIHBhY2thZ2UgbGlnaHRzcXVpZC0xLjgtYWx0Mgo= 4000 2009-10-22 12:28:13 +0400 2009-10-22 12:28:13 +0400 Добавлена сортировка и сравнение по правилам rpm test.sh application/x-shellscript 2231 kharpost IyEvYmluL2Jhc2gKCnJwbXNvcnQgKCkgewpsb2NhbCB1bnNvcnRlZCBzdHIxIHN0cjIgdG1wIHRt cG8gdG1wZSBsaW5lcyBpCnRtcG89IiQobWt0ZW1wIHRtcC5YWFgpIgp0bXBlPSIkKG1rdGVtcCB0 bXAuWFhYKSIKdW5zb3J0ZWQ9MQp3aGlsZSAoKHVuc29ydGVkKSk7IGRvCiAgdW5zb3J0ZWQ9MAog IHN0cjI9CiAgbGluZXM9IiQoc2VkIC1uICIkPSIgIiQxIikiCiAgZm9yICgoaT0xOyBpPD1saW5l czsgaSsrKSk7IGRvCiAgICBzdHIxPSIkKHNlZCAiJGkiJyFkJyAiJDEiKSIKICAgIFsgLXogIiRz dHIxIiBdICYmIGNvbnRpbnVlCiAgICBpZiBbIC16ICIkc3RyMiIgXTsgdGhlbgogICAgICBzdHIy PSIkc3RyMSIKICAgICAgY29udGludWUKICAgIGZpCiAgICBpZiBbICIkKHJwbWV2cmNtcCAiJHN0 cjEiICIkc3RyMiIpIiAtZ3QgMCBdOyB0aGVuCiAgICAgIHVuc29ydGVkPTEKIyAgICAgICBlY2hv ICJ0bXBvIgogICAgICBlY2hvICIkc3RyMSIgPj4gIiR0bXBvIgogICAgZWxzZQojICAgICAgIGVj aG8gInRtcG8iCiAgICAgIGVjaG8gIiRzdHIyIiA+PiAiJHRtcG8iCiAgICAgIHN0cjI9IiRzdHIx IgogICAgZmkKIyAgICAgICBlY2hvICJ0bXBlIgogICAgZWNobyAiJHN0cjIiID4gIiR0bXBlIgog IGRvbmUKICBlY2hvICIkc3RyMiIgPj4gIiR0bXBvIgogIGNhdCAiJHRtcG8iID4iJDEiCiAgOj4i JHRtcG8iCmRvbmUKcm0gLWYgIiR0bXBvIiAiJHRtcGUiCn0KCnBybiAoKSB7CiAgbG9jYWwgbGlu ZXMgaSBzdHIxIHN0cjIgY29uIHRtcAojICAgZWNobyAtbiAiJChzZWQgJzEhZCcgIiQxIikiCiAg bGluZXM9IiQoc2VkIC1uICIkPSIgIiQxIikiCiAgZm9yICgoaT0xOyBpPD1saW5lczsgaSsrKSk7 IGRvCiAgICBzdHIxPSIkKHNlZCAiJGkiJyFkJyAiJDEiKSIKICAgIFsgLXogIiRzdHIxIiBdICYm IGNvbnRpbnVlCiAgICBpZiBbIC16ICIkc3RyMiIgXTsgdGhlbgogICAgICBzdHIyPSIkc3RyMSIK ICAgICAgY29udGludWUKICAgIGZpCiAgICBlY2hvIC1uICIkc3RyMiIKICAgIGNvbj0iJChycG1l dnJjbXAgIiRzdHIxIiAiJHN0cjIiKSIKIyAgICB0bXA9Ij49PCIKIyAgICBlY2hvIC1uICIke3Rt cDpjb24rMToxfSIKICAgICBbICIkY29uIiAtbHQgMCBdICYmIGVjaG8gLW4gIj4iCiAgICAgWyAi JGNvbiIgLWVxIDAgXSAmJiBlY2hvIC1uICI9IgogICAgIFsgIiRjb24iIC1ndCAwIF0gJiYgZWNo byAtbiAiPCIKICAgIHN0cjI9IiRzdHIxIgogIGRvbmUKICBlY2hvICIkc3RyMiIKfQoKdG1wPSIk KG1rdGVtcCB0bXAuWFhYKSIKdG1wYT0iJChta3RlbXAgdG1wLlhYWCkiCnRtcG89IiQobWt0ZW1w IHRtcC5YWFgpIgpmb3IgcmVsIGluIGFsdDEuMTAgYWx0MS5wMyBhbHQxLjkgYWx0MS45LjEgYWx0 MS4xMC4xIGFsdDEuc3ZuMjAwOTA4MTIgYWx0MS5zdm4yMDA5MDgxMi4xMCBhbHQxLjEwLjEgYWx0 MS5zdm4yMDA5MDgxMi4xMTsgZG8KICBlY2hvIC1uICIkcmVsOiAiCiAgOj4iJHRtcCIKICBmb3Ig YnIgaW4gIiIgTTUwIE00MSBNNDA7IGRvCiAgICBmb3IgKChicmFuY2hfcmVsZWFzZV9udW09MTti cmFuY2hfcmVsZWFzZV9udW08PTI7YnJhbmNoX3JlbGVhc2VfbnVtKyspKTsgZG8KICAgICAgcnBt IC0tZGVmaW5lICJicmFuY2hfcmVsZWFzZV9udW0gXCIkYnJhbmNoX3JlbGVhc2VfbnVtXCIiIC0t ZGVmaW5lICJicmFuY2hfc3dpdGNoIFwiJGJyXCIiIC0tZXZhbCAiJWJyYW5jaF9yZWxlYXNlICRy ZWwiID4+IiR0bXAiCiAgICBkb25lCiAgZG9uZQogIHJwbXNvcnQgIiR0bXAiCiAgcHJuICIkdG1w IgogIGVjaG8KIyBzZWQgJzphO047cy9cbi8gLzt0YScgIiR0bXAiCiAgY2F0ICIkdG1wYSIgIiR0 bXAiID4gIiR0bXBvIgogIGNwIC1mICIkdG1wbyIgIiR0bXBhIgpkb25lCgpycG1zb3J0ICIkdG1w byIKcHJuICIkdG1wbyIKZWNobwoKY2F0IDw8RU9GID4iJHRtcCIKYWx0MS4xMAphbHQwLjEwLk01 MC4xCmFsdDAuMTAuTTQxLjEKYWx0MC4xMC5NNDAuMQphbHQwLjEwLk01MC4yCmFsdDAuMTAuTTQx LjIKYWx0MC4xMC5NNDAuMgoKRU9GCnJwbXNvcnQgIiR0bXAiCnBybiAiJHRtcCIKZWNobwoKcm0g LWYgIiR0bXAiICIkdG1wbyIgIiR0bXBhIgpleGl0CgpmaWxlIC92YXIvd3d3L2h0bWwvbGlnaHRz cXVpZC91c2VyX21vbnRoLmNnaSBmcm9tIGluc3RhbGwgb2YgbGlnaHRzcXVpZC1hZG1pbi0xLjgu MC4xLWFsdDIuMTEgY29uZmxpY3RzIHdpdGggZmlsZSBmcm9tIHBhY2thZ2UgbGlnaHRzcXVpZC0x LjgtYWx0Mgo=