[devel] Магия хэшей-кодов в зависимостях разделяемых библиотек

[Alexey Morozov]

Добрый вечер!

On 7 апреля 2012 18:03:56 Sergey Vlasov wrote:

> Насколько я понял, все эти пакеты *-unstable предполагалось в конечном
> итоге удалить из Сизифа; тогда, возможно, проще будет сначала их
> удалить явным образом, а потом уже собирать новую версию (попробовать
> сначала в одном задании, если не пройдёт с похожими ошибками -
> придётся сначала выносить отдельным заданием).

Ну, здесь есть два аспекта. Первое - я не совсем понимаю, как удалять пакеты 
из Сизифа:

for dp in libkdevplatformshell4-unstable-debuginfo \
   libsublime4-unstable-debuginfo libkdevplatformvcs4-unstable-debuginfo \
   libkdevplatformproject4-unstable-debuginfo \
   libkdevplatformlanguage4-unstable-debuginfo \
   libkdevplatformdebugger4-unstable-debuginfo \
   libkdevplatformutil4-unstable-debuginfo \
   libkdevplatformoutputview4-unstable-debuginfo \
   libkdevplatformdocumentation4-unstable-debuginfo \
   libkdevplatforminterfaces4-unstable-debuginfo;
do
   ssh git.alt build del $dp;
done

new task #68928: owner=morozov repo=sisyphus
girar-task add: Invalid request to delete nonexistent package 
`libkdevplatformshell4-unstable-debuginfo' from `sisyphus'
removing task #68928 ... done
new task #68929: owner=morozov repo=sisyphus
girar-task add: Invalid request to delete nonexistent package `libsublime4-
unstable-debuginfo' from `sisyphus'
removing task #68929 ... done
new task #68930: owner=morozov repo=sisyphus
girar-task add: Invalid request to delete nonexistent package 
`libkdevplatformvcs4-unstable-debuginfo' from `sisyphus'
removing task #68930 ... done

Я так понимаю, удалить отдельные подпакеты нельзя? И как это сделать в рамках 
одной транзакции со сборкой?

Второй момент связан вот с чем. Да, действительно, схема со стабильным и 
нестабильным kdevelop оказалась не слишком удачной, и в 4.3.0 я хотел удалить 
{kdevelop,kdevplatform}-unstable-*. Однако, совсем отказываться от пре-релизов 
тоже не хотелось бы, в 4.3.60+ уже сейчас есть всякие заманушки. Кроме этого, 
я считаю важным, что установленные пакеты пре-релизных версий не должны 
автоматически апгрейдиться до следующего пре-релиза. Например, если у человека 
установлен, например, пакет kdevelop-4.2.80 (с соотв. kdevplatform), то при 
появлении в репозитории kdevelop-4.3.0 и kdevelop-4.3.60 dist-upgrade должен 
происходить до 4.3.0, а не до 4.3.60 (и в локальном хэшере так и было, чес-
слово :)).

Поэтому я решил, что нестабильные сборки будут нести в имени некоторый 
уникальный для данной нестабильной ветки суффикс (для 4.3.60+ это -pre4.4), а 
следующая стабильная версия, когда она будет готова, должна такие пакеты 
обсолетить. Помимо этого, соотв. пакеты должны "во веки веков" обсолетить ещё 
и {kdevelop,kdevplatform}-unstable

Поэтому переводить ситуацию целиком на ручное управление очень не хочется. Но, 
с другой стороны, запихнуть в Sisyphus стабильный kdevelop тоже актуально.

С уважением,
Алексей Морозов