[pacman-dev] Libalpm direction and usage by others

Dario Freddi drf54321 at yahoo.it
Thu Mar 27 18:11:15 EDT 2008


>
> It is clear to us on the list that no one has really latched on to
> using libalpm.
Don't agree
>  To be honest, I don't blame anyone for this, as the
> interface seems to have been drawn at a bad level, and calling things
> like alpm_trans_commit() after 6 other functions and setting flags
> right just isn't intuitive.
>   
Agreed.
> So, what does this lead us to?
> 1. Document the existing interface better. Although it isn't perfect,
> we aren't going to get frontend clients without documentation. As all
> of us working on the one client that does use libalpm (pacman) have
> clearly not felt a need for further documentation, this is really
> going to have to be spearheaded by someone outside of our current
> "normal" developers. Anyone want to step up?
>   
Stop on that. When I started my work, I had only this 
(http://code.toofishes.net/pacman/doc/index.html) and the code. You know 
what? That was enough, and I didn't EVER complain about it. A competent 
programmer knows that, even if he had the best documentation around, 
sooner or later he will have to see the code to understand how things 
**really** work out. Sure, an improvement could be good, but don't 
forget that something is already out there.
> 2. Frontend developers need to speak up and get ideas on this list. I
> constantly see rhetoric like the above, where people say the current
> API is not very good, but they have not done a damn thing to change
> it. We can't read minds here, and we also aren't going to just change
> things on our own. So speak up people! If we get some good discussion
> going, we could really make changes to the API to make it usable.
>   
I once sent a mail, I proposed some ideas, I got one (1) answer, and... 
what? I proposed to abstract the backend, some real things, I'm writing 
a whole paper on that, I'm ready to show you something REAL, some real 
ideas, some people who really want to do that but... where is the list? 
Why just shining answered to my mail? Why didn't anybody else step up 
and said: "Ok good" or "No, sucks". You wanna see some code? Some 
efforts? Is that one enough? http://shaman.iskrembilen.com/trac.cgi/wiki
I wrapped libalpm around a C++ class and guess what? It works. It still 
has issues, but shaman works, and while I'm writing, a lot of people are 
using it, even if I still haven't put it on Arch bbs, since I want it to 
reach a real beta stage (where beta means usable, feature full, with 
some minor stuff, something we've almost achieved).
Will somebody listen to that now? Will somebody say that alpm, library 
or not, needs improvements and not in the code, in the basic ideas 
around it? Will somebody finally admit that it's time to hear other voices?

In my opinion, simplicity is also making life easier. Having a choice 
between db frontends is simple, since everyone can write its backend, 
and it gives the user freedom to use whatever it wants.
> 3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking
> "but that would be a step backwards!". Would it? I can tell you this-
> the pacman 2.9.8 codebase was about half the size of the current
> monster, and we have a lot of crazy design issues going on. Instead of
> trying to write a pacman library, why not just implement a friendly
> frontend, command-line interface, which is a bit more Unix-y? For
> example, monotone has its "automate" command (I haven't looked at this
> in some time, so let me know if I am wrong) that is designed to be
> used by other clients as machine-parseable. git is based around this
> concept as well- look at all the low level tools like rev-parse, etc.
> 4. Switch to something like python. I'm resistant to this idea.
> Although I think scripting languages like this have great benefits, I
> don't think pacman needs most of them. Having a package manager that
> always works is important to me, and part of me just thinks a
> low-level compiled language is the right thing for a system tool.
>   
Python or not, don't even think on that. First of all, all our efforts 
into shaman would be a waste. Secondly, you close every door through a 
different frontend than pacman, and I don't really think this is really 
the Arch way.
> Of the four options above, I have been pushing 1 and/or 2 for a long
> time. However, I am starting to lean toward option 3. I'd love to hear
> your thoughts on this.
>   
This is my thought. Out there, a lot of people have great ideas about 
pacman/alpm, but nobody here ever seemed to have listened to them. You 
asked for some code, I brought you Shaman. I'm ready to get up with some 
well documented ideas, but I don't know if there is the right attitude 
to accept other point of views. And I'm not talking about the SQLite 
stuff - I hate SQLite, and it sucks for a package manager. But 
honestly... would you give alpm the fault for all those void*s, for all 
that useless package structs, and whatever else?

There is someone who latched over libalpm, and it's me. I believed in 
it, even a lot of stuff was wrong, and the result is Shaman. You can say 
you don't like it, ok, that's fine. What you can't say is that it is a 
real step forward compared to gtkpacman & friends, that used pacman 
instead (I'm not saying they're bad, I'm just showing the difference in 
wrapping pacman and libalpm, gtkpacman still remains a piece of software 
IMHO)

> -Dan
>   
Didn't mean to offend anyone, sorry if I did.
Cheers
Dario




More information about the pacman-dev mailing list