[pacman-dev] Future pacman development (3.2/4.0)

[Travis Willard]

On Fri, 31 Aug 2007 13:27:29 -0700, eliott wrote
> On 8/31/07, VMiklos <vmiklos at 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