[devel] test a new build of APT, packagekit, synaptic, apt-indicator, aptitude, perl-AptPkg

[Ivan Zakharyaschev]

Добрый день!

On Thu, 17 Jun 2021, Aleksei Nikiforov wrote:

> 17.06.2021 15:03, Aleksei Nikiforov пишет:
> > 16.06.2021 18:14, Ivan Zakharyaschev пишет:

> > > К отправке в Sisyphus можно сказать готова новая сборка apt и
> > > зависящих от APT (клиентов библиотеки).

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

Спасибо за все за замечания! Учту и отвечу. (Последний вопрос я 
ожидал и могу ответить первым.)

> И ещё вопрос: в чём смысл откатывать изменения в коммите
> 2c25f00dd069abd6c4437e8d77188923c5cee9e2 и их же добавлять в коммите
> ea8efac4dd0a8b2cc82ce9e303d6a2d50f393682?

Дело в том, что после некоторой жизни с кодом apt, где копирование 
значений при передаче аргументов заменено тобой на передачу по ссылке 
(const), и посмотрев, что современные версии проектов, такие как 
PackageKit (где у тебя получается собирать самые свежие версии), всё же 
ориентируются на "традиционный" API Debian APT с копиями, а не ссылками, я 
подумал, что чуть проще будет жить, если оставаться совместимым с upstream 
в этой части API (предполагающей, что клиенты оверрайдят методы базовых 
классов).

Но не успел отребейзить кусочек истории apt, чтобы всё же вернуться в этой 
части к "традиционному" API. Хотел побыстрее предложить задание для 
тестирования. Эти два коммита, которые друг друга компенсируют -- 
заготовка, чтобы проще было собрать финальный релиз (без второго).

В целом мы, конечно, ломаем "традиционный" API в других местах, и я не 
против это делать ради разумных улучшений (типа этого), раз мы 
контролируем все связанные пакеты в Sisyphus, но здесь кажется, что 
выигрыш по скорости вряд ли заметен, а нагрузка на мейнтейнеров этих 
связанных пакетов пакетов немного, но всё же возрастает. Поэтому хочу 
отказаться от этой одной несовметимости с upstream-ами. (Подождём, пока 
оно не появится в upstream; может, само, может, мы пропихнём.)

Я эту мысль записал и в commit message:

commit 2c25f00dd069abd6c4437e8d77188923c5cee9e2
Author: Ivan Zakharyaschev <imz на altlinux.org>
Date:   Fri May 21 20:31:22 2021 +0300

    Revert "Migrate to new Apt ABI" -- to follow the order of the upcoming patches in APT
    
    Some of those upcoming patches also affect ABI, so we'd like to be
    able to build intermediate revisions of APT and PK and test them.
    
    This reverted change will be applied at the end of the current patch
    series. Or maybe not, because it brings just a dim advantage in speed
    by passing const arguments by reference whereas brings the
    disadvantage in being incompatible with upstream PackageKit (and with
    other clients of APT), which uses the current Debian's APT API
    (without this change); so, it adds a bit more burden on the maintainer
    for little gain.
    
    This reverts commit 42094b886f2d9965398ceb86b064a78b553d6557.
    
    (But keep all override marks on the methods from past commits.)

Да, ещё я собирал и проверял промежуточные коммиты в apt в комбинации с 
зависмыми пакетами. А там порядок такой сложился.

-- 
Best regards,
Ivan