On Sat, 25 Aug 2007 15:25:33 +0200 Xavier <shiningxc@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