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

[Robert Yang]

On 06/01/2012 06:35 PM, Koen Kooi wrote:
>
> 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.

I think that the broken-app_2.0_i586.ipk came unexpectedly,
there was a broken-app_1.0_machine.ipk (maybe also broken-app_1.0_i586.ipk,
but it didn't matter), if it has been fixed to version 2.0, then there should
be also a broken-app_2.0_machine.ipk (and it would be picked up).

// Robert

>
>> 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
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>