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

[Robert Yang]

On 05/26/2012 04:19 PM, Martin Jansa wrote:
> On Sat, May 26, 2012 at 04:15:09PM +0800, Robert Yang wrote:
>>
>>
>> On 05/26/2012 02:28 PM, Martin Jansa wrote:
>>> On Sat, May 26, 2012 at 10:47:31AM +0800, Robert Yang wrote:
>>>>
>>>>
>>>> On 05/25/2012 07:30 PM, Martin Jansa wrote:
>>>>> On Fri, May 25, 2012 at 01:19:55PM +0200, Koen Kooi wrote:
>>>>>>
>>>>>> Op 25 mei 2012, om 12:02 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.
>>>>>>>
>>>>>>> This is caused by opkg's selecting mechanism, if there are more than one
>>>>>>> candidates which have the same pkg name in the candidate list, for
>>>>>>> example, the same pkg with different versions, then it will use the last
>>>>>>> one which is the highest version in the list, this doesn't work for us,
>>>>>>> it should respect to the arch priorities in such a case.
>>>>>>
>>>>>> This is a serious break with the current opkg behaviour and I don't think it's an improvement. Needing different versions for non machine specific packages indicates a more serious bug elsewhere.
>>>>>
>>>>> It's not the same use-case as those 2 above, but what I don't like on
>>>>
>>>> Hi Martin,
>>>>
>>>> They are the same cases:-), I think that this patch has also fixed your problem,
>>>
>>> No, at least not completely the same.
>>>
>>> I would prefer to upgrade foo-1.0-r1_armv4t temporary until
>>
>> I think it can upgrade foo-1.0-r1_armv4t temporarily, if ipk/armv7a is removed
>> from the repository, then it would not appear in the opkg.conf, and the armv7a
>> should be the lowest priority and an unknown arch, and foo-1.0-r1_armv4t will
>> win, and it would be installed.
>>
>> I simulated your environment:(with core2 and i586, core2 has a higher version)
>>
>> 1) The foo-1.0_r1.core2 installed
>>
>> 2) Remove the core2 related lines from core-image-sato-1.0-r0/opkg.conf and
>> core-image-sato-1.0-r0/rootfs/etc/opkg/arch.conf
>>
>> 3) opkg update&&  opkg upgrade (foo-1.0_r1.i586 upgraded)
>>
>> 4) Add the core2 related lines back to core-image-sato-1.0-r0/opkg.conf and
>> core-image-sato-1.0-r0/rootfs/etc/opkg/arch.conf
>>
>> 5) opkg update&&  opkg upgrade (foo-1.0_r1.core2 upgraded)
>
> Heh, yes of course you can upgrade it with manual aproach on target, but
> try to explain it to end users who don't care about OE/opkg and they
> just assume that "opkg update&&  opkg upgrade" does right job and

I'm sorry I don't know what's your real product environment, but the
only "manual" approach that I use is edit the opkg.conf file:-), how can
you remove or add the armv7a feed back if you don't edit the opkg.conf file?
If you remove the ipk files on the disk without edit the opkg.conf file,
there would be errors when you run "opkg update"

// Robert

> upgrades their image to newer consistent set of packages.
>
> Cheers,
>
>>
>> // Robert
>>
>>> foo-1.0-r1_armv7a gets available in feed and that won't happen with your
>>> patch AFAIK.
>>>
>>> with your patch:
>>> If you have bar-1.0 which has to be MACHINE_ARCH and in 2.0 bar
>>> developers find way to detect and use all machine capabilities in
>>> runtime, recipe maintainer will switch to TUNE_ARCH, then
>>> foo-1.0_nokia900.ipk won't be ever upgraded to foo-2.0_armv7a.ipk
>>> and that's bad.
>>>
>>> Cheers,
>>>
>>>> the foo-1.0_armv7a will be kept now.
>>>>
>>>> // Robert
>>>>
>>>>> current opkg behaviour is that it doesn't "reinstall" the package with
>>>>> the same version when it gets available in arch with higher priority.
>>>>>
>>>>> e.g. I have armv7a device which has feed urls for armv4t and armv7a
>>>>> (armv7a of course with higher priority).
>>>>>
>>>>> foo-1.0 in both feeds armv4t armv7a
>>>>>
>>>>> opkg update&&    opkg install foo ->    foo-1.0_armv7a
>>>>>
>>>>> distro builder publish foo-1.0-r1 sofar only in armv4t feed
>>>>>
>>>>> opkg update&&    opkg upgrade ->    foo-1.0_armv7a is upgraded to foo-1.0-r1_armv4t)
>>>>>
>>>>> distro builder publish foo-1.0-r1 also to armv7a feed
>>>>>
>>>>> opkg update&&    opkg upgrade ->    nothing, but "upgrading" to foo-1.0-r1_armv7a) would be better
>>>>>
>>>>>
>>>>> On my distro builder I'm trying to prevent this scenario by rsyncing
>>>>> feeds only after build for *all* supported machines is completed, but
>>>>> that's still not really atomic operation. (And later I've also started
>>>>> to filter feeds which gets available on target image).
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Openembedded-core mailing list
>>>>> Openembedded-core at lists.openembedded.org
>>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>