Re: libapt-pkg introduction
On Fri, Oct 25, 2013 at 12:04 PM, <berenger.morel@neutralite.org> wrote:
> Le 25.10.2013 10:42, David Kalnischkies a écrit :
>> 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 do not really liked what I read in python-apt, since it does not uses the
> same names as those used in the C++ lib (which I intend to use, for various
> reasons). At least, that's what grep said.
I am not a python user myself, so I have no real idea, but I presume that
the names are just slightly different, e.g. mark_install → MarkInstall.
>> I guess part of the reason is that all simple examples are either
>> incomplete or no longer simple.
>
> Do you have any idea of where could be one of the incomplete ones?
> I do not need something which is really doing a useful job, I need something
> which shows the init process ( I have seen some "init" functions in
> python-apt... ).
> When I'll have that, with the doc and apt/aptitude to reverse, I should be
> fine and will hopefully be able to quickly have very basic tools.
You could have a look at the proof-of-concept reimplementation of
apt-show-versions in C++(11): [what is the state on that anyway?]
http://anonscm.debian.org/gitweb/?p=users/jak/apt-show-versions.git
It shows at least how to init various datastructures we use and do stuff
with them - even though all it does is read-only operations. The source
code for 'apt-get download' can show you how you can ask the system to
download packages for you, but for 'real' actions its probably just best
to look at the source for apt-get in general. It does a lot of output
and a lot of code deals with organising the output, but in-between it
reads actions from the commandline, deals with the fallout generated by
the actions requested, downloads packages and asks the underlying package
manager (=dpkg) to install them. I doubt aptitude is all that different
as it uses much of the same stuff, expect the "fallout" resolver.
Just ask if bits are unclear.
>> 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.
>
> Aptitude to do black magic must be acquired by pain :)
>
>> [It was (of course) never completed.]
>
> aptitude-gtk works, I think. At least, it did when I tried it 3 years ago...
> There is also synaptic which is used by a lot of people. But when I tried
> the graphical things, I was no longer able to intuitively use my keyboard to
> do what I wanted, so I quickly came back to my good old aptitude.
What I meant with 'ancient writings' are mails in the archives of this
list from 1997 which mention a graphical interface being in development.
My last information regarding aptitude-gtk is btw that it is unmaintained and
no longer build by default. Maybe you want to take over by adding keyboard-
driven interactions to it. ;) Aptitude developers will know more about that.
>> 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.
>
> Not a bad idea. And in case I can't make it looks like what I want I'll have
> code snippets. I'll go that way I think. I wonder what would be the easiest:
> starting with aptitude, or dselect?
Completely unbiased I would say: apt-get. :P
dselect is in so far different/strange as it is coming from dpkg-devs, but
usually operates by calling apt-get operations. I was also told its broken
in a few usecases nowadays and not used a lot anymore; but I personally
never touched it…
> PS: no need for cc ;)
I wasn't sure. Its usually the default on debian lists to not CC, but so
is <80 chars on a line… I see that playing safe was wrong this time, sry.
Best regards
David Kalnischkies
Reply to: