On Sat, Apr 07, 2012 at 10:38:54PM +0700, Alexey Morozov wrote:
> Добрый вечер!
> 
> On 7 апреля 2012 18:03:56 Sergey Vlasov wrote:
> 
> > Насколько я понял, все эти пакеты *-unstable предполагалось в конечном
> > итоге удалить из Сизифа; тогда, возможно, проще будет сначала их
> > удалить явным образом, а потом уже собирать новую версию (попробовать
> > сначала в одном задании, если не пройдёт с похожими ошибками -
> > придётся сначала выносить отдельным заданием).
[...]
> Я так понимаю, удалить отдельные подпакеты нельзя? И как это сделать в рамках 
> одной транзакции со сборкой?

Удаление производится по имени исходного пакета, удаляются все
собранные из него бинарные пакеты.

Добавление запроса на удаление пакета в задание:

  ssh git.alt task add [<task_id> [<before_subtask_id>]] del <package>

Или от этого unstable зависит что-то важное, что не хотелось бы
удалять?  Хотя, если удалять в том же задании, в котором собирается
новая версия, заменяющая пакет, такое задание должно пройти.

> Второй момент связан вот с чем. Да, действительно, схема со стабильным и 
> нестабильным 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

При такой схеме в стабильных версиях будут постепенно накапливаться
Obsoletes на -preX.Y.

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

Возможно, проблема сейчас возникает из-за недостаточно жёстких
зависимостей в старом unstable (типа той, про которую выдавалось
предупреждение при сборке новых пакетов).