[pacman-dev] Libalpm direction and usage by others

[Nagy Gabor]

> 3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking
> "but that would be a step backwards!".
Yes, I think so.;-)

> 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.
Well, I don't think we can easily compare the current codebase with
2.9.8. There were _dozens_ of bugs in 2.9.8, after 3.1.3 release we got
no "real" bugreport in FR. I think library is better than some
server<->client stuff, because now we can easily share internal things
with the front-end (for example: pkgcache) without interchanging tons of
data. So my vote: keep libalpm library.

Bye