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

[eliott]

On 8/31/07, VMiklos <vmiklos at frugalware.org> wrote:
> Hello,
>
> Na Fri, Aug 31, 2007 at 01:27:29PM -0700, eliott <eliott at cactuswax.net> pisal(a):
> > Actually, the config parser SHOULD be in the frontend.
>
> wrong. for example we have gfpm, a graphical frontend. having only a
> signle parser in libpacman to parser the configured repos is great, and
> i think all the users would be unhappy if they would have to always
> update gfpm's config accordingly

Its great that your shortcut is working out for you.
However, I wouldn't want to see an ugly shortcut become standard.

> > libalpm is a library. Libraries don't generally parse configs. They
> > receive config values through the api, at run time.
>
> really? just think of libsasl's /usr/lib/sasl2/smtpd.conf

I said 'generally', and you pick out one library. Well done.
Does libcurl have a conf file that it parses?

> > pacman is effectively a front end for libalpm. Thus, pacman should
> > parse the pacman.conf config file.
> >
> > 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.
>
> yes, of course. then please remove -ldownload from libalpm's LDFLAGS

I actually *do* think that libdownload should be in its own library.

You sure do have a snarky way of carrying on a discussion VMiklos.