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

[Martin Jansa]

On Mon, Jun 04, 2012 at 05:31:26PM +0800, Robert Yang wrote:
> 
> 
> 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).

If broken-app developers are now detecting machine capabilities (or
whatever) since 2.0 in runtime, then we don't need to build broken-app
for every single machine we support, so changing PACKAGE_ARCH from
MACHINE_ARCH to TUNE_PKGARCH is right thing to do to save compile time
and feed disk space.

Same use-case broken by this patch reported here:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/023154.html

Cheers,

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

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120604/89ee46bd/attachment-0002.sig>