[pacman-dev] Pacman Hooks

[Allan McRae]

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