TypicalPackagingErrors/versions
Типичные ошибки нумерования версий
...приводящие к неожиданным проблемам при последующем обновлении (e.g. 1.0 < 1.0pre лексикографически).
Subject: [sisyphus] Как правильно давать версию пакету? Date: Fri, 25 Nov 2005 16:50:32 +0200 From: Slava Dubrovskiy To: Sisyphus lists.altlinux.org Здравствуйте. Запаковал пакет с той версией какая указана в апстриме - 7.1PRE1. Теперь вышла 7.1.1 и апт считает, что 7.1PRE1 больше чем 7.1.1. Отсюда вопрос: что делать в данной ситуации и как правильно разрулить?
Поведение apt вполне объяснимо, ведь
~ $ rpmvercmp 7.1PRE1 7.1.1 1 ~ $
т.е. 7.1PRE1 действительно больше чем 7.1.1.
Выход в данной ситуации один. Давать номера пакетов вида: version-altx.prefix Например, в данной ситуации, было бы лучше версию PRE1 запаковать как 7.1-alt0.PRE1, а официальный релиз тогда имел бы версию 7.1-alt1 и т.д. Тоже самое предлагается делать и для cvs (например 7.1-alt0.cvs20051128) и всяких там alpha/beta/rc/pre. Сборка alt0 как раз визуально выделят версии cvs/pre из списка релизов.
То же самое относится и к пакетам имеющим iplXXmdk вместо altXX в номере сборки. Без смены версии пакета, менять iplXXmdk на alt (пусть даже и XX+1) не стоит!!! Не верите на слово:
~ $ rpmvercmp ipl23mdk alt4 8 ~ $
Если пакет с release вида alt0.cvsyyyymmdd собирается для backports, сообразно backports policy следует выставить его в alt0.0.cvsyyyymmdd; при этом "0" лексикографически меньше "c" и последуюшее обновление пройдёт успешно по крайней мере по этой части.
Надеюсь, что данная рекомендация попадет в полиси.
Еще бывает случай, когда у пакета с данными и пакета с кодом, в котором указана зависимость на пакет с данными определенной версии, изменяется версия.[1] В этом случае, при последовательной сборке, возможна такая следующая ситуация:
2010-Jun-09 22:27:03 :: task #25525 for sisyphus started: #1 build 3.3.4-alt1.svn477 from /people/andyc/packages/megaglest-data.git 2010-Jun-09 22:29:33 :: created pkg.tar for megaglest-data.git tag 3.3.4-alt1.svn477 2010-Jun-09 22:29:34 :: [x86_64] #1 megaglest-data.git 3.3.4-alt1.svn477: build start 2010-Jun-09 22:29:34 :: [i586] #1 megaglest-data.git 3.3.4-alt1.svn477: build start 2010-Jun-09 22:46:43 :: [x86_64] #1 megaglest-data.git 3.3.4-alt1.svn477: build OK 2010-Jun-09 22:48:31 :: [i586] #1 megaglest-data.git 3.3.4-alt1.svn477: build OK 2010-Jun-09 22:48:48 :: build check OK 2010-Jun-09 22:49:39 :: noarch check OK 2010-Jun-09 22:49:40 :: plan OK 2010-Jun-09 22:49:40 :: version check OK 2010-Jun-09 22:50:35 :: created test repo i586: NEW unmet dependencies detected: megaglest#3.3.1-alt1.svn110 megaglest-data = 3.3.1 x86_64: NEW unmet dependencies detected: megaglest#3.3.1-alt1.svn110 megaglest-data = 3.3.1 2010-Jun-09 22:50:39 :: dependencies check FAILED 2010-Jun-09 22:50:39 :: task #25525 for sisyphus FAILED
В данном случае, в Сизиф идет пакет версия которого изменилась, однако в Сизифе уже находится пакет с кодом, у которого в строке Requires, значится именно определенная версия пакета с данными
%define rev svn477 Name: megaglest Version: 3.3.4 Release: alt1.%rev Summary: Glest is a project for making a free 3d real-time customizable strategy game License: GPL Group: Games/Strategy Url: http://megaglest.sourceforge.net Packager: Andrew Clark <andyc@altlinux.org> Source: http://sourceforge.net/projects/%name/files/megaglest_3.2.3/%name-source-%version.tar.bz2 Source2: %name.sh Source3: %name.png Source4: %name.desktop #Patch1: glest-3.2.2-gentoo.patch # Automatically added by buildreq on Tue Jun 08 2010 BuildRequires: gcc-c++ imake jam libGL-devel libSDL-devel libX11-devel libcurl-devel libjpeg-devel liblua5-devel libopenal-devel libpng-devel libvorbis-devel libwxGTK-devel libxerces-c28-devel xorg-cf-files Requires: %name-data = %version
Из-за прямого указания версии пакета с данными, у пакета с кодом возникает неудовлетворенная зависимость, поэтому обновленная версия не проходит в Сизиф. Решение данной проблемы состоит в единовременной сборке двух пакетов:
ssh git.alt build megaglest-data 3.3.4-alt1.svn477 megaglest 3.3.4-alt1.svn477
TODO: добавить в policy и/или ссылку на него, если имеется