FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 07-05-2011, 12:36 AM
Sam Dunne
 
Default Declarative Diversions - Report 3

Hey all,
Not as much to report this time as I have previously
Since my last report things haven't moved as fast but the progress has been good. Basic code will be available by the end of the week for all to view and give feedback on. The ordering of calls to the new code has been decided and is currently being implemented locally for some testing.

The next week will be pushing for the release of preliminary code and after that it will be bug testing and working on feedbackIf anyone has any further questions let me know

--
Sam Dunne
 
Old 07-15-2011, 05:05 AM
Guillem Jover
 
Default Declarative Diversions - Report 3

Hi!

[ I mentioned this before, but could you try to send mails only in
plain text? Not in plain text and html? Thanks! ]

On Tue, 2011-07-05 at 01:36:22 +0100, Sam Dunne wrote:
> The next week will be pushing for the release of preliminary code and after
> that it will be bug testing and working on feedback
> If anyone has any further questions let me know

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.

Steve and Sam mentioned that it does not make sense to just reuse the
structs from src/filesdb.h just for reuse sake, because they add more
complexity. My point thought was that:

* Declarative diversions are more or less “built-in calls” to
dpkg-divert, so the code needs to update the diversions db to
add and remove entries there, the current code deals with
‘struct diversion’, no point in creating more parsers and loaders
for the db.
* The unpack code needs to deal with diversions, which are already
loaded from the diversions db, declarative diversions need to
update the db so that diverted files on the same dpkg run work.
This needs to use the existing infrastructure, not something
parallel.
* The current struct is not really that complex, and generating it
is just few lines of code as can be seen in ensure_diversions(),
the thing I can see making sense though it adding a new struct to
be used in the current code as a named constructor argument.
* This kind of duplicatoin it's generally a symptom something is
wrong, either in the new code or the old one.

Hope this clarifies.

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
parse_stanza():

<http://git.hadrons.org/?p=debian/dpkg.git;a=shortlog;h=pu/diversions>

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.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110715050555.GA32275@gaara.hadrons.org">http://lists.debian.org/20110715050555.GA32275@gaara.hadrons.org
 
Old 07-25-2011, 05:14 AM
Guillem Jover
 
Default Declarative Diversions - Report 3

Hi!

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
to rise?

> 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
> parse_stanza():
>
> <http://git.hadrons.org/?p=debian/dpkg.git;a=shortlog;h=pu/diversions>
>
> 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.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110725051458.GB4481@gaara.hadrons.org">http://lists.debian.org/20110725051458.GB4481@gaara.hadrons.org
 

Thread Tools




All times are GMT. The time now is 06:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org