On 30/01/11 09:05, Sascha Kruse wrote:
I hope i don't get annoying, but i have another question. At the moment I'm looking into the config parsing. Currenty, pacman parses the pacman.conf (pacman.c:_parseconfig(...)) into [section] key = value
And it assumes, that if section != "options" the section is a repo. To use pacmans config parsing i would like to generalize this a bit. My first idea is to change the syntax of the pacman.conf to [section] {subsection} key = value {subsection} ...
So a real world pacman.conf would look like [options] ... [hooks] {fonts} FIle = usr/share/fonts/* When = PostInstall [servers] {core} Server = ....
But the big disadvantage of this would be, well, that the syntax of pacman.conf changes.
My other idea is to generalize the _parseconfig(...) function so that it can parse an arbitrary config file with the given syntax. The result would be a alpm_list_t filled with:
typedef struct section { char *name; alpm_list_t *key_pairs; } section_t;
with
typedef struct key_pair { char *key; char *value; } key_pair_t;
This new _parseconfig(..) would then be used by a new parse_pm_config() and parse_hooks_config().In this case we would have a separate pacman.conf and hooks.conf. If this solution is used, should i move the _parseconfig(..) to a separate *.c file, or should it stay in pacman.c?
I prefer the generalized _parseconfig(..) but i wanted to hear your opinion first, before changing the config parsing.
I am very much in favour of the second option. From a distributions point of view, I would guess that a separate pacman-hooks package would be preferable as this would allow updating the hooks as needed, my like Arch does with the mirrorlist file. Thus obviously requires keeping the hooks config separate. As far as the idea for implementation goes, I think it seems a reasonable approach but I need to think on it some more. Allan