On Tue, Dec 10, 2019 at 10:27:54AM +0300, Oleg Solovyov wrote:
> On вторник, 10 декабря 2019 г. 03:30:42 MSK Dmitry V. Levin wrote:
> > On Fri, Dec 06, 2019 at 04:12:01PM +0300, Oleg Solovyov wrote:
> > > ---
> > > 
> > >  apt/apt-pkg/packagemanager.cc |   4 +-
> > >  apt/apt-pkg/packagemanager.h  |  30 +++++++-
> > >  apt/apt-pkg/rpm/rpmpm.cc      | 137 ++++++++++++++++++++++++++++++++--
> > >  apt/apt-pkg/rpm/rpmpm.h       |  16 ++--
> > >  4 files changed, 170 insertions(+), 17 deletions(-)
> > 
> > I agree the code should speak for itself, but it would be great
> > if you could shed some light on what's going on.
> We're introducing custom callback for higher layers (like packagekit), letting 
> them pass their own callbacks to APT instead of using rpmShowProgress when 
> it's necessary.
> It's useful in particular case of offline updating when packagekit can send 
> messages to plymouth letting user know about transaction progress but because 
> APT does not send anything since it's using rpmShowProgress, packagekit 
> reports nothing because it's just nothing to report.

Thanks, that's much better, and, btw, that's the main purpose of commit
messages - to let people know why you are doing this.

> > This looks ugly.  Could we use the same values for corresponding
> > APTCALLBACK_* and RPMCALLBACK_* constants instead?
> They're passed to packagekit.
> I don't think it's a good idea to let packagekit know something about RPM 
> internals.
> Better introduce something similar in APT than include RPM headers in 
> packagekit (which is two layers above RPM) I think.

There is definitely no need to expose rpm internals to apt clients.

If you prefer to define APTCALLBACK_* values this way,
could you think of an alternative customCallback implementation
that would be easy to verify?

For example, despite being a C++ project, you are still allowed
to use macros:

#define DEF_CASE(name)	case RPMCALLBACK_ ## name: return APTCALLBACK_ ## name


-- 
ldv