Re: opkg refactoring

[Peter Urbanec <openembedded-devel@urbanec.net>]

On 07/02/15 22:55, Paul Barker wrote:
> I didn't realise people were following oe-core master on deployments of a few
> thousand systems! This is definitely a use-case for the stable branches.

The deployed systems are currently on:

opkg mips32el 1:0.2.2-r0
opkg-collateral mips32el 1.0-r2
opkg-config-base beyonwizt4 1.0-r3

I'm currently testing a beta based on oe-core master. The info I have shown in the previous post is the state after I tried to apply my current beta release.

> Are you just seeing opkg-collateral left behind or are you seeing some other
> upgrades "stuck"?

So far I have only noticed this with the opkg packages.


> "opkg status opkg" should show that opkg now replaces opkg-collateral. As it is
> it's only showing provides and conflicts. In commit e8879cd, RREPLACES is
> modified to include opkg-collateral but that doesn't seem to have been
> propagated to the opkg package on your devices. If we can fix this you should be
> able to 'opkg upgrade' again and have the replacement properly handled.

The package on the test system does not have the correct replaces entries.

> Could you check whether "Replaces" for opkg includes opkg-collateral in your
> "Packages" file? And could you also check whether RREPLACES in
> "meta/recipes-devtools/opkg/opkg_0.2.4.bb" includes opkg-collateral? That should
> narrow down where the error is introduced.

The .bb file is correct, but I think you may have figured out the problem in the next paragraph.
 
> I'm also surprised your opkg version is "1:0.2.4-r0". Are you using the PR
> Service to ensure that version numbers increase each time a package is rebuilt?
> If not, this could contribute to the issue you're seeing.

I had PRSERV_HOST = "localhost:0" in the configuration, but it looks like a colleague has commented out that entry at some stage for some unknown reason. He also added some code to delete the manifests for images. :-( - I need to talk to him!

Maybe it would be helpful to enhance the PRServer check logic and not only print a NOTE: with the details when PRServer is started, but when there is no PRServer configured, print a *WARNING:* line to let the user know that they might run into all sorts of issues without PRServer.

In summary, it looks like the problem boils down to a stale package due to lack of PR service. I'll test that soon - I just have to rebuild everything.

Thanks very much for your help.

	Peter