Current Opkg Status

Michael 'Mickey' Lauer mickey at
Thu Feb 21 20:40:54 CET 2008

On Thursday 21 February 2008 20:07:25 Paul Sokolovsky wrote:
> Hello,
> On Wed, 20 Feb 2008 16:11:55 +0000
> Thomas Wood <thomas at> wrote:
> > Hi All,
> >
> > I've updated the Opkg wiki page to reflect the current state of
> > development.
> >
> >
> Quoting wiki:
> The following ipkg patches have been applied:
>     * "2-pkg-vec--Optimize-gross-inefficiency.patch" from OpenEmbedded
>     * "1-pkg-parse--Optimize-inefficient-parsing.patch" from
> OpenEmbedded
> As the author of those patches, I'd like to give some comments on them:
> 1-pkg-parse--Optimize-inefficient-parsing.patch
> 	This is for sure a must, it's fully correct algorithmically and
> does save lots of CPU cycles.
> 2-pkg-vec--Optimize-gross-inefficiency.patch
> 	This one is more "special". I hope you've read description
> within the patch. Summing up, it's pragmatic, heuristic optimization.
> At least one bug was submitted whose behavior can be partially
> attributed to this patch:
> . So, it *could* be
> attributed to the patch, which disables, so to say, running unique on a
> vector, hence the messages. But note that it happens due to disorder in
> feeds, and possibly ipkg would have issues in that case w/o patch
> still. As you see, I considered unapplying this patch, but as that
> issue wasn't re-raised and new problems weren't reported, I dared to
> leave it as is based on pragmatic reasoning that ipkg already has known
> issue handling corner cases, and having another such case is
> kind of acceptable regression comparing to speeding it up dozen of
> times - on each invocation and for each user.
> But I must mention these issue to you, as well as ideas how to handle
> that correctly (in the sense of not changing behavior of original
> algorithm):
> 1. Have 2 implementation of vector - with uniqueness check and w/o.
> 2. Analyze each use of vector class and use version w/o check where
> input to it is clearly unique (like keys of a hastable).
> 3. And unique vector's impl should be made smart - i.e., use linear
> search for no. of items < threshold, otherwise use hashtable.
> Actually, my first try on that patched attached hastable
> unconditionally to each vector, but hashtables are heavy, and there's a
> vector created for each package, so it quickly ate all memory.
> Finally, thanks for starting on decent embedded package manager. And I
> hope that you considered different alternatives. For example, I last
> time pondered idea to prototype something in Vala. I mention this
> because I found ipkg code to be pretty dirty, and just clean up of it
> would take effort.

This is actually a great thing, but at OpenMoko we found the need to improve 
the existing package manager due to time constraints (isn't it always like 
that?). Personally, I'd welcome a clean start in Vala though...


More information about the opkg-devel mailing list