[pacman-dev] Libalpm direction and usage by others

[Loui]

Hey there,
I've been thinking about libalpm recently since I started maintaining
aurbuild. I haven't looked at any of the code of libalpm (yet).
Yes, I have heard about how it's ugly and so on. I've seen all the
stalled attempts at creating python bindings as well.

I contacted one of those projects:

> The thing that has to be done before thinking of using pyalpm is
> implementing the transaction system from libalpm. It'll be a real
> pain because, until the last time I've checked it, it was made in a
> "flag-return_value-more_flag" way, which make it very hard to wrap
> for python (at least using pyrex, as I was). So good luck if you'll
> try

Well I'm still determined to try just to let you know. I'm willing to
provide input and get involved with libalpm eventually.

It could be useful for some other archlinux projects too like repoman
and pacbuild. And who knows, maybe even a sleek new python based,
command-line oriented AUR. I'm stretching, but this is a wacky idea
of mine. There was some casual talk among some AUR hackers about
hooking into libalpm back in October or something.

On Thu, 27 Mar 2008 12:33:18 -0500
"Dan McGee" <dpmcgee at gmail.com> wrote:

> It is clear to us on the list that no one has really latched on to
> using libalpm.
There could be all kinds of different reasons for this, but it's mostly
important that libalpm should work for pacman

> So, what does this lead us to?
> 1. Document the existing interface better.
Definitely

> 2. Frontend developers need to speak up and get ideas on this list.
Here I am. Though my input will be largely dependent on how my other
work progresses. There's only 24 hours in a day unfortunately.

> 3. Scrap the whole libalpm/split idea.
I guess that would depend on the purpose libalpm was created in the
first place. If you could ever envision more than one application using
the libraries at the same time I would vote to keep libalpm. I can
imagine a setup where I have a software checking the database, building,
and installing packages in a syncronised manner.

It seems that at least one app (shaman) uses libalpm in a serious manner
so it would be kind of mean to scrap it. But I guess you can't be
nice for nice's sake. Hah.

> 4. Switch to something like python.
Though that might make things easier for me (and some others), I don't
think it would really be a good approach for pacman/libalpm. Unless it
was pyrex, or cython maybe hah. But still I'd say no.

Cheers!