[OE-core] [PATCH 1/1] opkg 0.1.8: respect to the arch when choose the alternatives

[Koen Kooi]

Op 1 jun. 2012, om 12:02 heeft Richard Purdie het volgende geschreven:

> On Fri, 2012-06-01 at 11:04 +0200, Koen Kooi wrote:
>> Op 1 jun. 2012, om 10:17 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Thu, 2012-05-31 at 17:01 +0200, Koen Kooi wrote:
>>>> Op 31 mei 2012, om 16:13 heeft Robert Yang het volgende geschreven:
>>>> 
>>>>> There is a bug if we:
>>>>> 1) bitbake core-image-sato-sdk MACHINE=qemux86
>>>>> 2) bitbake core-image-sato with MACHINE=crownbay
>>>>> 
>>>>> Then several pkgs in deploy/ipk/i586 would be installed to crownbay's
>>>>> image even if there is one in deploy/ipk/core2 and we have set the
>>>>> core2's priority higher than i586, when the version in deploy/ipk/i586 is
>>>>> higher. This doesn't work for us, for example, what the crownbay need is
>>>>> xserver-xorg-1.9.3, but it installs xserver-xorg-1.11.2.
>>>> 
>>>> And this is working exactly as intended. Don't break opkg because your
>>>> hardware driver situation sucks.
>>>> 
>>>> So: NAK on this patch.
>>> 
>>> I think we do have a problem here. For example, the system is ignoring a
>>> PREFERRED_VERSION directive here
>> 
>> A PREFERRED_VERSION set in a machine.conf, which is the wrong place.
> 
> Its strongly not recommended. You can do it and if things are setup
> correctly, we do support machine specific alterations however...
> 
>> Let's change the above build sequence to this:
>> 
>> 1) MACHINE=qemux86 bitbake xserver-xorg
>> 2) MACHINE=othercore2machine bitbake xserver-xorg
>> 3) MACHINE=crownbay bitbake xserver-xorg
>> 
>> Oh look, I get 1.11.2 on crownbay regardless of this patch.
> 
> I've been assuming this xserver is marked as machine specific. If its
> not, that is a bug and we can fix that.

the X server not machine specific and that is NOT a bug. The recipe for the DDX only works with a specific X version. The real problem here is that xf86-video-something (again, not machine specific, think pci cards) has a strict requirement on the x server version. This is now purely a DISTRO problem. A few possible solutions are:

1) Lock X to 1.9.3 for all compatible x86 archs in your DISTRO
2) Lock X to 1.11.2 for all compatible x86 archs in your DISTRO, live with the crownbay breakage
3) Only use a package manager with no notion of compatible archs (dpkg) or with strong version pinning (rpm)
4) Be really careful with the build sequence and structure your feed configs to not have compatible archs in their feed URIs
5) remove 'x11' from DISTRO_FEATURES

This is a point where you cannot make everybody happy. But as you say below, let's decouple the above problem from the arch vs version discussion.

>>> by building one thing and then
>>> installing another. We're also inconsistent between the dpkg/rpm and
>>> opkg backends. There is therefore definitely some kind of user
>>> experience issue at stake here since this behaviour is not obvious,
>>> expected or particularly correct.
>>> 
>>> The fact the example is hardware related is not particularly relevant,
>>> its the bigger picture I worry about
>> 
>> I also worry about the bigger picture, especially about what Martin
>> said about this breaking feeds.
> 
> As far as I understood Martin's comments, this actually helps avoid some
> of the issues he's been experiencing with feeds?

No, it allows you to add a package-of-death. Example:

broken-app_1.0_machine.ipk is in the feeds, being machine specific
broken-apps author fixes the machine specific bits properly
broken-app_2.0_i586.ipk hits the feeds and is not picked up.

> Martin has a problem where machines are ending up with unoptimised
> versions of code on them and it would be good to fix opkg behaviour to
> do what people expect...

Yes, feed updates are not atomic, but this patch breaks moving packages between archs like the broken-app example above. In angstrom a machine doesn't see feeds with compatible archs at runtime, e.g. beagleboard sees beagleboard, armv7a and noarch URIs. This reduces these kind of problems to images built with OE. I must note that this setup for feed URIs was done out of bandwidth, storage and ram concerns (good old ipkg), not to avoid Martins problems :)

regards,

Koen