Re: [pacman-dev] Pacman Hooks

29 Jan 2011

      2011/1/29 Dan McGee <dpmcgee@gmail.com>:
...
On Sat, Jan 29, 2011 at 2:20 PM, Sascha Kruse <knopwob@googlemail.com> wrote:
...
2011/1/29 Dan McGee <dpmcgee@gmail.com>:
...
On Sat, Jan 29, 2011 at 8:36 AM, Sascha Kruse <knopwob@googlemail.com> wrote:
...
 - The "File" argument can't begin with a / because it is matched
against alpm_pkg_get_data and that
     file-strings don't have the leading /
This is a must-have, your logic is backwards. We never assume the
install root is /; file paths in all install scripts should be written
this way too, not to mention everywhere in the library. So nothing
wrong here, it would be wrong if you did any prefix whatsoever.
I get your point, but i think it would be confusing for the users.
I would intuitively write File = /usr/share/fonts/*
instead of File = usr/share/fonts/*.
So maybe we should accept both and in the latter case ignore
the leading / ?
Maybe I wasn't clear.
We will *not* take a patch that prefixes paths with anything,
anywhere, anytime. pactest is a perfect example of relative dbpaths
and dbroots that this needs to work for.
Okay, understood.

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.

Greetings,
Sascha