[pacman-dev] Libalpm direction and usage by others

[Dan McGee]

On Thu, Mar 27, 2008 at 10:42 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Thu, Mar 27, 2008 at 9:16 AM, Xavier <shiningxc at gmail.com> wrote:
>  > Raymano Garibaldi wrote:
>  >  >
>  >  > You can not expect people to use an API that has no clear
>  >  > documentation and no stable interface that they can count on. And you
>  >  > can not expect a developer to try to figure out an API by scanning
>  >  > mailing lists, at least not this one. If it takes anyone longer to
>  >  > figure out an API than write their own software, well guess what
>  >  > they're going to do.
>  >  >
>  >
>  >  Then why don't they write an API with a clear documentation and a stable
>  >  interface so that everyone could reuse it ? :)
>
>  Or, better yet, document the API, or help us document it?

It is clear to us on the list that no one has really latched on to
using libalpm. 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.

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?
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.
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.

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.

-Dan