Re: libapt-pkg introduction
Hi!
On Thu, Oct 24, 2013 at 1:15 PM, <berenger.morel@neutralite.org> wrote:
> I hope I am asking help on the good list, I was not sure about which one to
> choose between debian-devel, dpkg and this one.
You came to the right place :)
The deity@ mailinglist is the 'maintainer' of libapt-pkg, apt-get (and co),
so you are perfectly on topic (python-apt is also discussed here) as we talk
here about changes to the overall APT-environment as well as APT itself.
aptitude-centered discussions on the other hand can be found at:
aptitude-devel@lists.alioth.debian.org
dpkg@ is for the tool itself as well as big changes to the handling of
packages effecting everyone (think: MultiArch, Crossbuild dependencies, …)
Last not least, debian-devel@ is kinda catch-all for discussing everything
(at least slightly) related to Debian.
You will have a good chance of running into much of the same people either
way through as the developers in the APT-environment are brothers in arms
and leave the fight of which is the better front-end to the fanboys. ;)
Finally, you will find some folks also idling on IRC in #debian-apt.
> But it seems to be a python-apt related documentation, not libapt-pkg. So do
> someone knows if there is some very short and quick introduction that I
> could use as a starting point, or will I have to take a look directly in
> aptitude's or apt-get's source codes?
There unfortunately isn't much documentation available, and based on your
description you found all of it already. If you like what you read in
python-apt, I suppose it isn't that different from libapt - beside the
obvious language difference of course.
I guess part of the reason is that all simple examples are either incomplete
or no longer simple. Legend has it that apt-get and friends are demos on
how package management could be done (with libapt) until the implementation
of the graphical 'apt' would be completed. It's at least how I interpret some
of the ancient writings. [It was (of course) never completed.]
I would recommend taking whatever front-end comes closest to what you want
it to be and patch the hell out of it until it is what you want. The initial
cost of understanding code from others might be high at first, but starting
from scratch usually means that you write a lot of code unrelated to what you
want to achieve in the first place. It also helps to have others to ask/blame
for all the bugs you encounter along the way - it's at least how I do it. ;)
Best regards
David Kalnischkies
Reply to: