Re: Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 breaks opkg

[Mike Westerhof <mike@mwester.net>]

Graham Gower wrote:
> 2009/12/4 Mike Westerhof <mike@mwester.net>:
>> Commit 2fdf1aa1c869ea9deecee86206f49a2eca9d7c00 (Koen) breaks
>> opkg-nogpg-nocurl.  I have no idea what else might be broken, but the
>> fact that it removes all the critical patches that make it work on
>> small-memory machines is the most obvious cause of the breakage.
>>
>> So what do you all want me to do about this?  We can revert the commit.
>> Or someone can try to sort out a way to let opkg change without
>> impacting the tiny-memory version of opkg (which will get more and more
>> difficult as the two diverge).  Or I can just create
>> opkg-nogpg-nocurl-slugos.bb in hopes that it won't get stomped on.
>>
>> Thanks,
>> Mike (mwester)
> 
> Since slugos is at r160, perhaps adding those patches back in, with
> maxrev= lines is best for now?

That would fall into the category of (b) - trying to sort out how to let
the opkg-nogpg-nocurl recipe change while keeping it building for
systems with very very small memory.

As a reminder, the need is that opkg must run in 32MB of physical RAM -
it cannot be assumed that swap space is available - and an absolute
minimum of dependencies on external libraries is required because the
total rootfs image must fit in about 5 MB or so.

I don't have much flexibility with opkg.

So back to the issue.  Someone with enough smarts on how that recipe was
just changed (and opkg_svn.bb, opkg.inc are included because they too
changed) can put back the patches and anything else that would ensure
that no extraneous dependencies have been added.  I realize that someone
will point the finger at me, but honestly I have no time to do that.

Hence I suggested the other two options.  Revert the change, so that
SlugOS builds again, and then whomever decided that a wholesale cleanup
of opkg recipes was necessary can go back in and try again.

Or if OE in general decides they want the nice new tidy opkg for some
unknown benefits it provides, well, I suggested that I simply create yet
another recipe for opkg, one that will duplicate the working opkg for
SlugOS, at least until I find time to invest to try to figure out why
versions >160 have never worked.  (Please understand that testing opkg
is a laborious process, requiring many different test scenarios that
involve lots of reflashing of images... it's time I just do not have
right now to invest, particularly since there is no net benefit as far
as I can see to this recent change to all the opkg stuff.)

So I'm leaning toward the latter solution right now - I don't want to
anger those who found the opkg recipe rewrites beneficial.  So I'll
rephrase it now:  If you have valid objections to my creating a custom
SlugOS opkg recipe, voice those concerns now. :)

Thanks,
Mike (mwester)