LINUX.ORG.RU

Сравнение и сортировка версий пакетов ПО

 


0

2

Интересно и не очень понятно, как это реализовано где-либо, в частности, в Gentoo Portage и DPKG.

Вступление. Если у нас версии ПО имеют вид, например, 10.11, 12.13.14, 15.16.17.18 - всё легко и просто, можем работать с ними, как со строками, где символы - числа, разделённые точками, и сортировать как-бы лексикографически. А сортировать нам нужно, чтобы узнать, какую версию выбрать, как самую свежую из доступных. Ну и уметь просто сравнить нужно, чтобы узнать, доступно ли повышение версии.

Встречается такая вариация: 10.11.12-13, а ещё в deb-пакетах (не вникал, зачем) фигурирует первое число с двоеточием: 10:11.12.13-14. Допустим, мы можем все эти разделители (:, -) заменить на точки и работать по предыдущей схеме.

Но ещё есть такая фигня, как release candidate, обычно версия записывается как 10.11-rc12. При этом, по задумке, версия 10.11 будет _выше_, чем 10.11-rc12, и вот тут в голове у нас что-то больно хрустит.

А ещё в deb-пакетах часто строка версии просто отвал башки:

zlib1g                                    1:1.2.3.4.dfsg-3ubuntu4
xz-lzma                                   5.1.1alpha+20110809-3
xkb-data                                  2.5-1ubuntu1.3
vim                                       2:7.3.429-2ubuntu2.1
ucf                                       3.0025+nmu2ubuntu1
tzdata                                    2014e-0ubuntu0.12.04
sysv-rc                                   2.88dsf-13.10ubuntu11.1
ntfs-3g                                   1:2012.1.15AR.1-1ubuntu1.2
login                                     1:4.1.4.2+svn3283-3ubuntu5.1
librtmp0                                  2.4~20110711.gitc28f1bab-1
libroken18-heimdal                        1.6~git20120311.dfsg.1-2

Вопросы:

1. Я продвигал rc-версии своих пакетов в Portage Tree, например. Не ломает ли запись типа 1.2.3-rc4 механизма сравнения там?

2. Сейчас я поддерживаю ПО, которое пакетится (и пакетилось ранее) в deb-дистрибутивы с версиями типа 1:2.3.4-5 в пакетах, для человеков анонсированная версия озвучивается как 2.3.4 или 2.3.4-5. Часть после дефиса наращивается в случае исправлений пакетирования. Я понимаю, что 4 числа многовато и можно одно выкинуть, когда-нибудь этим займёмся. Тэги Git тоже держим в формате v2.3.4-5. Какова необходимость именно в части после дефиса для deb-пакетов, правильно ли это согласно политик deb-пакетирования, и насколько стрёмно использовать эту часть в случае дистрибуции пакетов на другие пакетные системы?

3. Какие общие best practices в плане версионирования, чтобы не страдать экзотичностью и избегать потенциальных проблем? Если придерживаться формата 1.2.3[.4], то, по идее, никаких проблем быть не должно. Но вот ядро использует rc, насколько хорошо системы пакетов обрабатывают эти случаи?

Я продвигал rc-версии своих пакетов в Portage Tree, например. Не ломает ли запись типа 1.2.3-rc4 механизма сравнения там?

В portage есть установленные правила обзывания версий. В общем виде см File Naming Rules и если твои поделия не нарушают эти правила то всё ок.

(cut) и насколько стрёмно использовать эту часть в случае дистрибуции пакетов на другие пакетные системы?

Не скажу за всё… Но опять же в gentoo ebuild вполне может иметь одну версию в то время как то что собственно он собирает может иметь немного другую версию. Опять же все зависит от того насколько это оправдано и куда именно ebuild должен попасть.

Какие общие best practices в плане версионирования, чтобы не страдать экзотичностью и избегать потенциальных проблем? Если придерживаться формата 1.2.3[.4], то, по идее, никаких проблем быть не должно. Но вот ядро использует rc, насколько хорошо системы пакетов обрабатывают эти случаи?

Опять же на мой взгляд в gentoo версии ebuild-ов реализованы лучше всего. По крайней мере учтены любые желания и случаи.

Интересно и не очень понятно, как это реализовано где-либо, в частности, в Gentoo Portage и DPKG.

Конкретное описание алгоритмов того как это реализовано в gentoo можно найти в Package Manager Specification по каждой конкретной версии EAPI. А реализацию этих алгоритмов смотри:

При желании это ^ запросто переделывается в обычный bash скрипт потому что именно им оно по сути и является.

init_6 ★★★★★
()

Но ещё есть такая фигня, как release candidate, обычно версия записывается как 10.11-rc12. При этом, по задумке, версия 10.11 будет _выше_, чем 10.11-rc12, и вот тут в голове у нас что-то больно хрустит.

О том как это в gentoo для EAPI=5 --> Names and Versions

init_6 ★★★★★
()
Ответ на: комментарий от anonymous

вырубает такой стиль

2 anonymous ты вон там обрати внимание кто автор… и как мне так норм. По крайней мере тесты почти все проходит а это главное.

Меня вообще это интересовало потому что я хотел автоматический выбор версии запилить… Т.е. чтоб к примеру был ebuild - geek-sources-3.14.ebuild а дальше чтоб оно само искало самое свежее ядро в ветке 3.14 и дальше таким же не хитрым способом подбирало бы и версии всех остальных патчей если они не заданы пользователем конкретными значениями. Когда теперь руки до этого дойдут я не знаю…

init_6 ★★★★★
()
Ответ на: комментарий от devl547

Portage традиционно продолжит тормозить на обработке зависимостей?

А ты уже написал патчи ускоряющие portage на 900% но не знаешь куда посылать патчи или просто очередной раз традиционно потроллить над „тормозящими portage“?

Нытики которые вопят о „тормозящем portage“ забывают что они „тормозами“ расплачиваются за все фичи которые им предоставляет portage. И фичей этих немало если хотя бы немного о них задуматься. На мой взгляд порочная практика только в том, что portage тянет все от 0 до 5-х EAPI сразу в то время как старое дерьмо обязано сгореть в огне АДА! И кроме этого имеет… сколько там на самом деле - полтора разработчика?

init_6 ★★★★★
()
Ответ на: комментарий от init_6

забывают что они „тормозами“ расплачиваются за все фичи которые им предоставляет portage

За раздутый legacy-код, написанный на коленке на питоне?

старое дерьмо обязано сгореть в огне АДА!


Да, вот только избавление от старых EAPI не принесёт особого профита.

devl547 ★★★★★
()
Последнее исправление: devl547 (всего исправлений: 1)
Ответ на: комментарий от devl547

За раздутый legacy-код, написанный на коленке на питоне?

А тебя кто-то насильно заставляет юзать portage? Вали на LFS там тормозов от расчета зависимостей как и самих расчетов зависимостей нет вовсе. Профит же!

Да, вот только избавление от старых EAPI не принесёт особого профита.

С чего-то надо начинать? К тому же последствия разработки portage вон вместо того чтоб ускорять emerge -s запилили тупо новую утилиту eix и подобных примеров полно.

Вообще этот очередной разговор про тормозящий portage бессмысленный.

init_6 ★★★★★
()
Последнее исправление: init_6 (всего исправлений: 1)
Ответ на: комментарий от init_6

да ничего особого, просто мне не нравится, когда then пишут в одну строку с if через точку с запятой - выглядит некрасиво

anonymous
()
Ответ на: комментарий от devl547

ну так покажи этим portage-ламерам как надо делать современные вещи, чё попусту верещать-то?

вообще тормоза портежа начинаются с ростом количества установленных пакетов, в только что развёрнутом stage3 портеж реактивен, а вот когда установленных пакетов больше тысячи - да, зависимости по десятку секунд обсчитываются

anonymous
()
Ответ на: комментарий от anonymous

да ничего особого, просто мне не нравится, когда then пишут в одну строку с if через точку с запятой - выглядит некрасиво

Там все равно в проверке есть особо упоротый бред на котором оно спотыкается… Но в основном все вменяемые версии оно сравнивает нормально.

init_6 ★★★★★
()
Ответ на: комментарий от Krieger_Od

Так а как оно работать будет? Как софтина сортировать версии будет?

man deb-version

fopen ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.