[Apt-Rpm] Aptness -- a simplified interface for libapt-pkg

[João Abecasis]

Gary L. Greene Jr. wrote:
> On Monday 17 September 2007 07:07:32 pm João Abecasis wrote:
> > Gary L. Greene Jr. wrote:
> > > Is this built to work with Apt-RPM's variant of libapt-pkg or Debian's?
> > > There are large incompatible differences between the two.
> >
> > Currently it only works with Apt-RPM. Supporting both is part of the plan.
> >
> > Part of the path we're going is to completely hide libapt-pkg behind
> > our interface. Given that, we could either support Debian's Apt with
> > recourse to #ifdef's, as long as the differences are reconcilable.
> > Otherwise, it could be a completely different backend.
> >
> > I'll have to look further into it, though.
>
> Using #ifdefs everywhere is going to make your code VERY difficult to
> maintain....

Yes, that's a concern for us as well. It's what I (wanted to) allude
to when I mentioned "reconcilable". #ifdef'ing will only be an option
if it is contained and doesn't become a maintenance nightmare. Of
course, the real fix would be to merge the projects at the Apt level.

> The big problem with libapt-pkg is that it's API knows _far_ too much about
> the capabilities of the underlying container format and it's installer
> engine. This is coupled very deep in libapt-pkg. When Gustavo initially
> ported APT to RPM, he had to rip out the stuff in it that was intimately tied
> to dpkg.

Another part of the problem, as I see it, is that the API is too
low-level and requires knowledge of internal implementation details of
Apt for proper use. My perception is that projects using libapt-pkg
end up repeating large portions of code from apt-get and similar
tools.

While I'm bashing the library interface (sorry!... :-p), I also think
there should be a clearer separation of the interface into independent
functional modules. For instance, I'd like to see repository (apt,
repomd, urpmi...), package manager (rpm, dpkg), actions (install,
remove...) and dependency resolution algorithms (upgrade,
dist-upgrade...) all orthogonal to each other.

These are things that can be provided on top of the current code base.
Also better interface documentation is needed... I haven't tackled
this one either, but it needs to be addressed for Aptness.

> Thus until either the new libept takes over the duties that libapt-pkg does
> (which has a clean API compared to libapt-pkg and has rudimentary read
> support for RPM), your best option at this point is to have two separate
> class implementations that are used by a main class that #ifdefs to the
> different backends. This will lower the sheer amount of code branching in
> your main library API and allow you to isolate the differences within the
> separate class implementations.

Hmm... I guess aptness directly competes with libept, as we seem to
have the same goal. I remember looking into it, but probably moved
away because it didn't support Apt RPM.

I'll have to dig deeper into that one. I'm sure we could work together.

> Weee fun, the joys of good OO encapsulation. :D

:-)

Cheers!


João Abecasis