Re: [PATCH 1/1] opkg 0.1.8: respect to the arch when choose the alternatives

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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 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 know that hardware issue sucks
and many people on this list have experienced pain due to it, we'd all
like it to go away. Using this as a reason not to examine and
potentially fix some problematic package manager behaviour is not right
IMO though. The world isn't perfect, sucky hardware/software exists, we
need to work with it.

So to be honest I'm leaning towards taking the patch. I would be
interested in other people's opinions though...

Cheers,

Richard