Re: Declarative Diversions - Report 3
On Fri, 2011-07-15 at 07:05:55 +0200, Guillem Jover wrote:
> [ I mentioned this before, but could you try to send mails only in
> plain text? Not in plain text and html? Thanks! ]
[ Just found your private mail from the other day on my spam box.
Please try to send your mails to the list, so that other people can
chime in. ]
> I only skimmed over the spec and the code so I've not done a proper
> review of those yet, but there's few things I think are clear enough
> regardless. Some of these I mentioned on IRC yesterday but you were
> not present, so I'll repeat them here:
> * We should reuse parts of the parser from lib/dpkg/parse.c, I've some
> code now to refactor that, but I realized we don't need to untie
> the code from pkginfo because the declarative diversions are tied
> to a specific package anyway so those will serve a purpose, but
> yes from control file stanza parsing.
> * The new code should live under src/ where all the other files db
> related code resides, moving those to libdpkg right now does not
> make sense anyway.
> * All db related allocations should be done using the non-freeing
> malloc (nfmalloc).
> * The code is reinventing its own diversion structs, which are already
> in src/filesdb.h.
I've not seen any reaction to this on your git branch nor on the list,
is there any counter-argument for some of those points you guys wanted
> I've pushed some preliminary refactoring to pu/diversions in my repo,
> so that you get an idea of what I mean, the key function here is
> The code has only been build tested, and there's few things I don't
> quite like about it. I'll be away during the weekend starting today,
> but I'll clean that up once I come back.
>From the IRC log on #debian-dpkg I'm given to understand you have not
checked that branch contents?
You can grab it with something like this on your current git tree:
git remote add guillem git://git.hadrons.org/git/debian/dpkg.git
git remote update guillem
The function you should be checking is parse_stanza() as mentioned
above, you'll need to pass to it a function pointer that takes care
of parsing each different field. You could use either the ‘struct
fieldinfo’ infrastructure for that or something else. You'll need to
call parse_stanza() from a loop similar to the one in parse.c.
I'm sorry I've not been able to push a cleaned up branch but I've had
unexpected guests and ended up not having time. The cleanup should not
affect the resulting code in a big way, so it should be ok to depend
on the current interfece there.