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

Ivan Zakharyaschev imz на altlinux.org
Вт Июн 22 12:26:25 MSK 2021


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


Подробная информация о списке рассылки Devel