On Fri, 31 Aug 2007 13:27:29 -0700, eliott wrote
On 8/31/07, VMiklos <vmiklos@frugalware.org> wrote:
having the config parser in the frontend is a very very bad idea imho, just i don't want to flame on this list all the day ;)
Actually, the config parser SHOULD be in the frontend.
Well, maybe it's better to say the config parser SHOULDN'T be in libalpm - where it SHOULD be is still up for debate. (leading up to your comment below)
libalpm is a library. Libraries don't generally parse configs. They receive config values through the api, at run time.
pacman is effectively a front end for libalpm. Thus, pacman should parse the pacman.conf config file.
Thinking about it further, I do agree with you - libalpm is not the place for config parsing. However, I still think that there are too many options in pacman.conf that shouldn't be tied directly into the 'pacman' frontend for libalpm - splitting up configuration files into 'pacman' specific stuff and generic stuff (like mirror lists, servers, and so on) should still be a must. (leading up to your comment below some more)
There could certainly be a configuration parsing library, that front-ends can share, but it doesn't need to be tied into libalpm. That should just handle package management.
Now this, I think, is a cool idea. Keep libalpm pure, but still provide a way for multiple front-ends to share the configuration data that, IMO, _needs_ to be shared between front-ends. Something like... "libalpm-config" because I'm creative that way. I'm not sure if it should be a generic config-file-reader or if it should specifically be designed to load only the backend-config options, such as servers, and pass the necessary info into libalpm. So, my points are: 1) Backend configuration should be split into a different file from frontend configuration. 2) A library outside libalpm should be responsible for parsing, at least, the backend configuration file and feeding that into libaplm, to maximize code re-use. Please comment and help me flesh this out - I think we're on the right track here. If we can get a solid idea of what would be the best way to handle this, I'll start hacking it together. -- Travis