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

[Travis Willard]

On Sat, 25 Aug 2007 15:25:33 +0200
Xavier <shiningxc at gmail.com> wrote:

> On Sat, Aug 25, 2007 at 09:13:50AM -0400, Travis Willard wrote:
> > 
> > lmao - looks like I'm a little late into this discussion, aren't I?
> > Oh, well, if you guys really think it belongs in the frontend, I
> > guess that's where it's going to stay.
> > 
> 
> I don't really have any strong opinion on this.
> But now vmiklos got some backup :p
> Considering it has just recently been moved back to the frontend,
> where it originally was, I don't see it moving again any time soon
> though. So I'm afraid you are a bit late indeed.
> 
> But maybe just wait for Dan's answer on your concerns :)

I suppose.  It came up for me looking at writing a pacman PackageKit
back-end.  I realized I'd have to parse the config file, which really
boiled down to nearly copying the parsing code directly out of the
pacman code and pasting it into whatever I was doing.  

It occurred to me that this is probably going to happen in nearly every
front-end that gets written, so that people can use command-line and GUI
front-ends with the same config file, because seriously, who expects the
front-end you're using to change which repos etc. you connect to?

In any case, my coder's instinct kicked in and said "hey, if this code
is going to be reused everywhere, why not put it in a common place, ie.
libalpm?"

I've read through the thread where VMiklos argued about the download
code existing in libalpm.  I agree with many of his arguments, actually
- have the library provide a default download implementation and use a
callback mechanism for frontends to override it.  

The same would also hold for configuration - one of the
counter-arguments was "pacman.conf is pacman's configuration file,
other frontends would be wise to use their own config file" and it's
silly - you expect users or software maintainers to reconfigure umpteen
config files to point to the same repositories. What if Arch gets some
new official repos?  Then everyone who decides to write a frontend
needs to add it to their configs - the duplication of work is totally
unnecessary. I say split out the frontend's configuration options from
the backend's configuration options, and make two config files, each
handled by their respective place in the code.   That makes it easier
on everyone, IMO, and is smarter all around.

--
Travis