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

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

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

Здравствуйте!

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

Потестируйте заранее, если кому-то интересно. Вдруг выявится новая ошибка.
Из задания 265991

apt-repo add 265991
apt-get update
apt-get ...

Там очень много коммитов в этом релизе, но для пользователей особо ничего 
нового нет. Наоборот даже, до восстановления в следующем релизе убрано 
динмаическое наращивание размера кэша информации о пакетах из 
0.5.15lorg2-alt70. 

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

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

-- 
Best regards,
Ivan

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

[Pavel Vasenkov]

Коллеги, добрый вечер.
В Ср, 16/06/2021 в 18:14 +0300, Ivan Zakharyaschev пишет:
> Здравствуйте!
> 
> К отправке в Sisyphus можно сказать готова новая сборка apt и 
> зависящих от APT (клиентов библиотеки).
> 
В новую сборку не вошли закрытия багов
https://bugzilla.altlinux.org/show_bug.cgi?id=38277
https://bugzilla.alt
linux.org/show_bug.cgi?id=39834

Решено http://git.altlinux.org/people/pav/packages/apt.git
В какой версии сборки их можно ожидать?

> 
> Потестируйте заранее, если кому-то интересно. Вдруг выявится новая
> ошибка.
> Из задания 265991
> 
> apt-repo add 265991
> apt-get update
> apt-get ...
> 
> Там очень много коммитов в этом релизе, но для пользователей особо
> ничего 
> нового нет. Наоборот даже, до восстановления в следующем релизе
> убрано 
> динмаическое наращивание размера кэша информации о пакетах из 
> 0.5.15lorg2-alt70. 
> 
> Суть в приведении кода в вид, который будет чуть легче поддерживать, 
> добавлять что-то с несколько меньшей опасностью что-то сломать и
> который 
> сейчас уже внушает опасений чуть менее, чем раньше. (Надеюсь.)
> 
> (Менять исходники для этого релиза больше нет планов. Только может
> что-то 
> сокрее косметическое в оформлении коммитов, истории пакетов.)
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Aleksei Nikiforov]

16.06.2021 18:14, Ivan Zakharyaschev пишет:
> Здравствуйте!
> 
> К отправке в Sisyphus можно сказать готова новая сборка apt и
> зависящих от APT (клиентов библиотеки).
> 
> Потестируйте заранее, если кому-то интересно. Вдруг выявится новая ошибка.
> Из задания 265991
> 
> apt-repo add 265991
> apt-get update
> apt-get ...
> 
> Там очень много коммитов в этом релизе, но для пользователей особо ничего
> нового нет. Наоборот даже, до восстановления в следующем релизе убрано
> динмаическое наращивание размера кэша информации о пакетах из
> 0.5.15lorg2-alt70.
> 
> Суть в приведении кода в вид, который будет чуть легче поддерживать,
> добавлять что-то с несколько меньшей опасностью что-то сломать и который
> сейчас уже внушает опасений чуть менее, чем раньше. (Надеюсь.)
> 
> (Менять исходники для этого релиза больше нет планов. Только может что-то
> сокрее косметическое в оформлении коммитов, истории пакетов.)
> 

Здравствуйте.

По поводу packagekit:

Прошу убрать коммит
3cca5d3c17fa231a8e8917913ce5604051171d42: хотя оказывается C++ такое 
позволяет, я бы предпочёл чтобы объявление и реализация функции имели 
одинаковый вид. Тем более в ea8efac4dd0a8b2cc82ce9e303d6a2d50f393682 эта 
разница убирается.

Коммит a8eae29920917fac7eb2cb2f90eaa0a0493b33d6: вызов 
"_error->Discard();" будет лучше перенести в деструктор класса 
AptCacheFile. В коммите 75268b692844314957875c0f8cd365086467fe6d 
добавляется ещё одно место, где удаляется и пересоздаётся инстанс 
AptCacheFile, а вот вызов "_error->Discard();" там не добавили. Т.е. 
получается потеряли?

Есть ли смысл оставлять коммит 7ca8eaec9829820841d49c15d36c0520f1faf58b 
с учётом наличия 75268b692844314957875c0f8cd365086467fe6d? Я думаю, 
стоит его тоже просто удалить.

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

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

[Aleksei Nikiforov]

17.06.2021 15:03, Aleksei Nikiforov пишет:
> 16.06.2021 18:14, Ivan Zakharyaschev пишет:
>> Здравствуйте!
>>
>> К отправке в Sisyphus можно сказать готова новая сборка apt и
>> зависящих от APT (клиентов библиотеки).
>>
>> Потестируйте заранее, если кому-то интересно. Вдруг выявится новая 
>> ошибка.
>> Из задания 265991
>>
>> apt-repo add 265991
>> apt-get update
>> apt-get ...
>>
>> Там очень много коммитов в этом релизе, но для пользователей особо ничего
>> нового нет. Наоборот даже, до восстановления в следующем релизе убрано
>> динмаическое наращивание размера кэша информации о пакетах из
>> 0.5.15lorg2-alt70.
>>
>> Суть в приведении кода в вид, который будет чуть легче поддерживать,
>> добавлять что-то с несколько меньшей опасностью что-то сломать и который
>> сейчас уже внушает опасений чуть менее, чем раньше. (Надеюсь.)
>>
>> (Менять исходники для этого релиза больше нет планов. Только может что-то
>> сокрее косметическое в оформлении коммитов, истории пакетов.)
>>
> 
> Здравствуйте.
> 
> По поводу packagekit:
> 
> Прошу убрать коммит
> 3cca5d3c17fa231a8e8917913ce5604051171d42: хотя оказывается C++ такое 
> позволяет, я бы предпочёл чтобы объявление и реализация функции имели 
> одинаковый вид. Тем более в ea8efac4dd0a8b2cc82ce9e303d6a2d50f393682 эта 
> разница убирается.
> 
> Коммит a8eae29920917fac7eb2cb2f90eaa0a0493b33d6: вызов 
> "_error->Discard();" будет лучше перенести в деструктор класса 
> AptCacheFile. В коммите 75268b692844314957875c0f8cd365086467fe6d 
> добавляется ещё одно место, где удаляется и пересоздаётся инстанс 
> AptCacheFile, а вот вызов "_error->Discard();" там не добавили. Т.е. 
> получается потеряли?
> 
> Есть ли смысл оставлять коммит 7ca8eaec9829820841d49c15d36c0520f1faf58b 
> с учётом наличия 75268b692844314957875c0f8cd365086467fe6d? Я думаю, 
> стоит его тоже просто удалить.
> 

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

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

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

Добрый день!

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

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

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

Hello!

On Thu, 17 Jun 2021, Aleksei Nikiforov wrote:

> По поводу packagekit:
> 
> Прошу убрать коммит
> 3cca5d3c17fa231a8e8917913ce5604051171d42: хотя оказывается C++ такое
> позволяет, я бы предпочёл чтобы объявление и реализация функции имели
> одинаковый вид. Тем более в ea8efac4dd0a8b2cc82ce9e303d6a2d50f393682 эта
> разница убирается.

(ea8efac4dd0a8b2cc82ce9e303d6a2d50f393682 я всё же в итоговой версии хочу 
пропустить, как я писал.)

Можно ещё, чтобы был одинаковый вид и было формально зафиксировано 
свойство реализации (что в реализации функции эти переменные менять не 
приходится), добавить const в объявление в header-е.

> Коммит a8eae29920917fac7eb2cb2f90eaa0a0493b33d6: вызов "_error->Discard();"
> будет лучше перенести в деструктор класса AptCacheFile. В коммите
> 75268b692844314957875c0f8cd365086467fe6d добавляется ещё одно место, где
> удаляется и пересоздаётся инстанс AptCacheFile, а вот вызов
> "_error->Discard();" там не добавили. Т.е. получается потеряли?

Справедиливое замечание, что можно сказать, что его потеряли. Или не 
обработали ошибки. Просто раньше как бы вообще была неправильная 
реализация поведения в этом месте, и там ни Close(), ни деструктор не 
вызывался, не было эффекта и ошибки не обрабатывали.

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

Так и сделаю сейчас, если ты не скажешь, что у тебя предпочтения 
поменялись. Потому что так тоже можно в качестве эквивалента старого кода.

> Есть ли смысл оставлять коммит 7ca8eaec9829820841d49c15d36c0520f1faf58b с
> учётом наличия 75268b692844314957875c0f8cd365086467fe6d? Я думаю, стоит его
> тоже просто удалить.

Согласен.

Заодно переупорядочиваю коммиты, чтобы исправление ошибки было ближе к 
upstream-у и можно было его отправить.

-- 
Best regards,
Ivan