opkg 0.1.8: respect to the arch when choose the alternatives

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.

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 10 lines

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.

Quoted 5 lines

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.

Quoted 13 lines · Koen Kooi

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 10 lines

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.

Quoted 7 lines

Quoted 5 lines

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 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).

Quoted 19 lines · Koen Kooi

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 15 lines

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.

Quoted 1 line

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

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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 24 lines · Martin Jansa

Quoted 22 lines · Koen Kooi

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 10 lines

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.

Quoted 5 lines

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.

Quoted 1 line

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, the foo-1.0_armv7a will be kept now.

// Robert

Quoted 30 lines

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,

Quoted 4 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 20 lines · Martin Jansa

Quoted 19 lines · Koen Kooi

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 15 lines

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.

Quoted 3 lines

Quoted 1 line

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,

the foo-1.0_armv7a will be kept now.

// Robert

Quoted 33 lines

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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 23 lines · Martin Jansa

Quoted 20 lines · Koen Kooi

Quoted 19 lines

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 15 lines

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.

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

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 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.

Op 26 mei 2012, om 08:28 heeft Martin Jansa het volgende geschreven:

Quoted 38 lines · Robert Yang

Quoted 23 lines · Martin Jansa

Quoted 20 lines · Koen Kooi

Quoted 19 lines

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 15 lines

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.

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

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 foo-1.0-r1_armv7a gets available in feed and that won't happen with your patch AFAIK.

Quoted 6 lines

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.

And what's worse, the cited usecase is for (slightly paraphrasing):

xserver-xorg 1.11.2 i586
xserver-xorg 1.9.3 i686

Which indicates there is a different, more serious problem at hand. It seems that someone is trying to encode machine specific tweaks to non-machine specific packages. I'm more interested in solving that problem than in changing opkg/rpm behaviour.

There are a number of things that are just not possible to do when supporting multimachine builds and/or multimachine feeds. For example:

machine dogbeachmountain (i686) needs xf86-video-evilpowervr-closedbinary that only works with Xorg 1.9, but machine cherryblossomhighway (i586) can use xf86-video-intel with any xserver-xorg.
If you want both of these machines to work in multimachine builds and/or feeds, you need to lock down xserver-xorg to 1.9 for i*86. If you don't want to lock it down and imgtec won't give you a better binary drop, too bad, stop doing multimachine. I'm not saying the above situation is what Robert is trying to solve, but it's a situation meta-ti is currently facing with the new binary drop for SGX support. When you have dealt with SGX blobs everything starts to look like an SGX problem :)

regards,

Koen

Quoted 27 lines · Robert Yang

Quoted 23 lines · Martin Jansa

Quoted 13 lines · Koen Kooi

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 10 lines

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 3 lines

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

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,

Quoted 37 lines

the foo-1.0_armv7a will be kept now.

// Robert

Quoted 33 lines

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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 28 lines · Martin Jansa

Quoted 27 lines · Robert Yang

Quoted 23 lines · Martin Jansa

Quoted 13 lines · Koen Kooi

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 10 lines

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 7 lines

Quoted 3 lines

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)

// Robert

Quoted 50 lines

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,

Quoted 37 lines

the foo-1.0_armv7a will be kept now.

// Robert

Quoted 33 lines

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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 53 lines · Robert Yang

Quoted 28 lines · Martin Jansa

Quoted 27 lines · Robert Yang

Quoted 23 lines · Martin Jansa

Quoted 13 lines · Koen Kooi

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 10 lines

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 7 lines

Quoted 3 lines

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)

Quoted 4 lines

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

upgrades their image to newer consistent set of packages.

Cheers,

Quoted 53 lines

// Robert

Quoted 50 lines

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,

Quoted 37 lines

the foo-1.0_armv7a will be kept now.

// Robert

Quoted 33 lines

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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 54 lines · Martin Jansa

Quoted 53 lines · Robert Yang

Quoted 28 lines · Martin Jansa

Quoted 27 lines · Robert Yang

Quoted 23 lines · Martin Jansa

Quoted 13 lines · Koen Kooi

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 10 lines

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.

Quoted 7 lines

Quoted 5 lines

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

Quoted 7 lines

Quoted 3 lines

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)

Quoted 8 lines

Quoted 4 lines

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

Quoted 58 lines

upgrades their image to newer consistent set of packages.

Cheers,

Quoted 53 lines

// Robert

Quoted 50 lines

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,

Quoted 37 lines

the foo-1.0_armv7a will be kept now.

// Robert

Quoted 33 lines

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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:

Quoted 10 lines

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.

Quoted 5 lines

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.

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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 for both denzil and master branch.

[YOCTO #2360]

Signed-off-by Robert Yang<[email protected]>

---
  .../opkg/opkg/respect-to-arch.patch                |   47 ++++++++++++++++++++
  meta/recipes-devtools/opkg/opkg_0.1.8.bb           |    1 +
  meta/recipes-devtools/opkg/opkg_svn.bb             |    1 +
  3 files changed, 49 insertions(+), 0 deletions(-)

create mode 100644 meta/recipes-devtools/opkg/opkg/respect-to-arch.patch

meta/recipes-devtools/opkg/opkg/respect-to-arch.patch new file +47 -0

new file mode 100644
index 0000000..6f4537f
@@ -0,0 +1,47 @@
+pkg_hash.c: respect to the arch priorities when good_pkg_by_name
+
+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,
+it should respect to the arch priorities in such a case.
+
+Upstream Status: Pending
+
+Signed-off-by: Robert Yang<[email protected]>
+---
+ libopkg/pkg_hash.c |   18 +++++++++++++++---
+ 1 files changed, 15 insertions(+), 3 deletions(-)
+
+diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
+index a99cf6b..cc048c8 100644
+--- a/libopkg/pkg_hash.c
++++ b/libopkg/pkg_hash.c
+@@ -376,10 +376,22 @@ pkg_hash_fetch_best_installation_candidate(abstract_pkg_t *apkg,
+           if (constraint_fcn(matching, cdata)) {
+              opkg_msg(DEBUG, "Candidate: %s %s.\n",
+ 			     matching->name, matching->version) ;
+-             good_pkg_by_name = matching;
++             /* Respect to the arch priorities when given alternatives */
++             if (good_pkg_by_name) {
++                 if (matching->arch_priority>= good_pkg_by_name->arch_priority) {
++                     good_pkg_by_name = matching;
++                     opkg_msg(DEBUG, "%s %s wins by priority.\n",
++                         matching->name, matching->version) ;
++                 } else
++                     opkg_msg(DEBUG, "%s %s wins by priority.\n",
++                         good_pkg_by_name->name, good_pkg_by_name->version) ;
++             } else
++                 good_pkg_by_name = matching;
+ 	     /* It has been provided by hand, so it is what user want */
+-             if (matching->provided_by_hand == 1)
+-                break;
++             if (matching->provided_by_hand == 1) {
++                 good_pkg_by_name = matching;
++                 break;
++             }
+           }
+      }
+
+--
+1.7.1
+

meta/recipes-devtools/opkg/opkg_0.1.8.bb +1 -0

index c206b37..5161824 100644
@@ -3,6 +3,7 @@ require opkg.inc
  SRC_URI = "http://opkg.googlecode.com/files/opkg-${PV}.tar.gz \
             file://add_vercmp.patch \
             file://headerfix.patch \
+           file://respect-to-arch.patch \
            "
 
  PR = "${INC_PR}.0"

meta/recipes-devtools/opkg/opkg_svn.bb +1 -0

index c07d393..c3ed973 100644
@@ -6,6 +6,7 @@ SRC_URI = "svn://opkg.googlecode.com/svn;module=trunk;proto=http \
             file://fix_installorder.patch \
             file://offline_postinstall.patch\
             file://track_parents.patch \
+           file://respect-to-arch.patch \
  "
 
  S = "${WORKDIR}/trunk"