TypicalPackagingErrors/versions: различия между версиями

Текущая версия от 20:52, 11 июня 2010

Эта страница была перемещена с freesource.info.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.

Типичные ошибки нумерования версий

...приводящие к неожиданным проблемам при последующем обновлении (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 и/или ссылку на него, если имеется

[1] Живой пример.

[1]

@@ Строка 37: / Строка 37: @@
 Еще бывает случай, когда у пакета с данными и пакета с кодом, в котором указана зависимость
 на пакет с данными определенной версии, изменяется версия.<ref>[http://lists.altlinux.org/pipermail/devel-newbies/2010-June/000465.html Живой пример.]</ref> В этом случае, при последовательной сборке,
-возможна такая следующая ситуация:
+возможна такая ситуация:
 <pre>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
@@ Строка 56: / Строка 56: @@
 -Jun-09 22:50:39 :: dependencies check FAILED
 -Jun-09 22:50:39 :: task #25525 for sisyphus FAILED</pre>
-В данном случае, в Сизиф идет пакет версия которого изменилась, однако в Сизифе
+В данном случае, в Сизиф идет пакет с данными, версия которого изменилась, однако в репозитории
 уже находится пакет с кодом, у которого в строке Requires, значится именно
-определенная версия пакета с данными
+определенная версия пакета с данными:
 <pre>
 %define rev svn477
@@ Строка 82: / Строка 82: @@
 Requires: %name-data = %version
 </pre>
-Из-за прямого указания версии пакета с данными, у пакета с кодом возникает
+Из-за прямого указания зависимости на версию пакета с данными, у пакета с кодом возникает
 неудовлетворенная зависимость, поэтому обновленная версия не проходит в Сизиф.
 Решение данной проблемы состоит в единовременной сборке двух пакетов: