Если пакет не обновляется, но обновляются пакеты, от которых он зависит, то бэкпорт не обновляется из-за того, что у него ниже версия. Желательно, чтобы при запуске rpmbph устанавливал релиз не alt0, а alt<%release-1>, чтобы его версия оказывалась больше старой. Эта ситуация описана здесь: http://www.altlinux.org/BackportsPolicy Пример разумного исключения: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Если необходимо предотвратить возможность обновления с релиза вида alt0.DISTRO.REVISION до сизифовского alt7 при наличии в Сизифе alt8 (в том числе в случае серьёзной ошибки, исправленной в alt8), можно сделать релиз вида alt7.DISTRO.REVISION, при условии что за основу взят именно alt8 а не alt7."
Является ли допустимым, что rpmbph будет узнавать текущую версию пакета в бранче через обращение к сайту http://sisyphus.ru ?
Даже не знаю... Ну, на конкретном примере: http://sisyphus.ru/find.shtml?request=python-module-setuptools 0.6-alt1.c8 Такая же версия и в Сизифе и в M40, поэтому когда собирается бэкпорт, то получается версия 0.6-alt0.M40.1.c8 которая меньше, чем оригинальная. Наверное, подразумевалось что должно быть как-то так: 0.6-alt1.M40.0.c8 Наверное, простое правило %release-1 работать не будет...
(In reply to comment #2) > Даже не знаю... Ну, на конкретном примере: Ещё раз. Для того, чтобы обеспечить правильный релиз при одинаковых версиях в сизифе и бранче, нужно узнать, какой релиз сейчас в бранче, и учесть это в релизе портируемого пакета. И я спрашиваю, как скрипту rpmbph узнать версию пакета в бранче, допустимо ли получать её с сайта sisyphus.ru
Хреново. Лучше уж у APT-а.
Я не помню, предлагал ли я это публично, но у меня была идея, что эту (поиск в sisyphus.ru) функциональность нужно сделать опциональной, а также ввести возможность указывать версию в бранче через дополнительный параметр. В итоге получаем три варианта использования: 1) текущий - всегда устанавливается alt0.DISTRO.RELEASE (при это не требуется интернет во время пересборки) 2) версия-релиз в бранче устанвливаются вручную через опцию (интернет снова не нужен) 3) версия-релиз в бранче выясняются на sisyphus.ru (во время сборки требуется доступ к интернету) Я думаю, что третий вариант подходит для постоянного использования, но поскольку коллизии не только с интернетом, но и самим sisyphus.ru, по первые два варианта стоит оставить... Возможно 3 вариант должен быть по умолчанию, возможно так делать не стоит...
Хорошую идею высказал Михаил, с получением версии из репозитория. Она может быть неактуальной, но это другой вопрос. А как узнать от апта версию пакета? Парсить apt-cache show пакет?
Я скорее имел в виду - прямо из apt-ового источника на ftp.altlinux.org (благо URLы бранчевых репозиториев хорошо известны), с соответсвующим кэшированием (тривиальным, по ETag или Last-Modified). Вытащить версию пакета из pkglist.classic.bz2 - пять строк на том же python+python-rpm.
(In reply to comment #5) Во, мне больше всего нравится вариант номер два: > 2) версия-релиз в бранче устанвливаются вручную через опцию (интернет снова > не нужен) Думаю, эта ситуация возникает не так часто, чтобы ее нельзя было разрулить вручную.
(In reply to comment #8) > (In reply to comment #5) > > 2) версия-релиз в бранче устанвливаются вручную через опцию (интернет снова > > не нужен) > > Думаю, эта ситуация возникает не так часто, чтобы ее нельзя было разрулить > вручную. > Только сам вспоминал этот вариант с мыслью о том, что механизм получения версии в бранче действительно стоит разнести с механизмом пересборки... Тогда можно сделать несколько вариантов отдельных утилит, которые могут получить по имени пакета версию и релиз... При этом, кроме опции с ручным указанием, можно добавить опцию с указанием имени утилиты, которая будет использована для получения по имени версии и релиза в бранче... В этом случае не будет ограничений на источник сведений о текущих пакетах. Этим источником можно будет сделать sisyphus.ru, аптовые базы или обычный файл со списком имён и версий пакетов...
(In reply to comment #8) > Во, мне больше всего нравится вариант номер два: > > 2) версия-релиз в бранче устанвливаются вручную через опцию > > (интернет снова не нужен) > Думаю, эта ситуация возникает не так часто, чтобы ее нельзя > было разрулить вручную. +1
Начиная с 1.5.1 при бэкпортировании устанавливается релиз как 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
