Шаги воспроизведения: $ alteratorctl systeminfo branch p11 # alteratorctl packages repo add p10 # alteratorctl packages repo remove p10 Получаемый результат: $ alteratorctl systeminfo branch p10 $ alteratorctl packages repo list rpm [p11] http://ftp.altlinux.org/pub/distributions/ALTLinux p11/branch/noarch classic rpm [p11] http://ftp.altlinux.org/pub/distributions/ALTLinux p11/branch/x86_64 classic rpm [p11] http://ftp.altlinux.org/pub/distributions/ALTLinux p11/branch/x86_64-i586 classic Ожидаемый результат: $ alteratorctl systeminfo branch p11 Получаемый результат еще можно было бы ожидать, если бы команда alteratorctl packages repo add p10, работала аналогично команде apt-repo set, но она же так не работает.
Перевешиваю на hromovpi@altlinux.org
Добрый день! Команды alteratorctl packages repo add p10 alteratorctl packages repo remove p10 alteratorctl systeminfo branch вызывают следующие команды: apt-repo add p10 apt-repo rm p10 rpm --eval %_priority_distbranch Передача бранча в apt-repo add, судя по коду, приводит к установке переданного бранча в %_priority_distbranch: sub add_repo { shift; my $repo = shift; my $object = shift; my @comps = @_; my $a_found; my $i_found; my @c = (); my @priority_branches = ( "p10", "p11", "sisyphus" ); my @urls = get_url( $repo, $object, @comps ); # Set %_priority_distbranch foreach my $distbranch ( @priority_branches ) { if( not $dry_run and ( $repo eq $distbranch or ( defined($object) and $object eq $distbranch ) ) ) { open PRIORITY, '>', "/etc/rpm/macros.d/priority_distbranch" or die "Can't open /etc/rpm/macros.d/priority_distbranch: $!"; print PRIORITY "%_priority_distbranch $distbranch\n"; close PRIORITY; } } То есть это не ошибка alteratorctl, а особенность поведения apt-repo add.
Думаю, что поведение соответствует предполагаемому ожиданию by design. Нигде p11 для того, чтобы к нему вернуться, не хранится. Можно подумать и предусмотреть это в рамках редакций. Но это уже более комплексная задача.
