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>:
...
...
 - 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
On Sat, Jan 29, 2011 at 8:36 AM, Sascha Kruse <knopwob@googlemail.com> wrote:
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