Re: [RFC PATCH 1/2] opkg svn: Add the --force-arch option

[Robert Yang <liezhi.yang@windriver.com>]

Hi All,

Thank you very much for your suggestions, do we have a final solution
or work around please?

If we refer to the rpm, it doesn't care about the package's version, it
just selects the newest build package, I had applied a patch to make it
respect to the arch before.

It seems that we have no good solution for the PREFERRED_VERSION
pkg during the package installation, what does the package management
system knows is the arch's priority, the PREFERRED_VERSION pkg always
has a higher priority than others in the feed. So maybe respect to the
arch is the only way that we have current.

I'd like to submit such a patch if you are OK with it:

Let the arch priority win the higher version is the default way for opkg,
and add an option (--select-higher-version) for it to make the higher
version win the arch priority, so that the user can have another choice.

// Robert

On 09/09/2012 04:40 AM, Paul Eggleton wrote:
> On Saturday 08 September 2012 21:08:55 Phil Blundell wrote:
>> a) for people who are not using O_P_M, it's becoming apparent that the
>> whole concept of using opkg (or rpm, or any other external package
>> manager) for rootfs construction is more of a liability than an asset
>> because bitbake has more knowledge about which particular binaries ought
>> to be installed.  For those use-cases, it might be better to think in
>> terms of abolishing opkg altogether which would solve this problem and a
>> variety of others.
>
> On the other hand, using the package manager for rootfs construction for those
> that *are* using online package management allows us to have at least some
> confidence that a rootfs produced directly from the metadata and one produced
> by on-system upgrades will be the same; you can also have package management
> on in one image and off in another (or change it on the fly) and expect to have
> the same contents, apart from the package manager being removed. The potential
> for subtle differences in behaviour is too great to go down the path of
> implementing it ourselves IMO, not to mention the extra code paths to
> maintain.
>
>> b) for people who _are_ using O_P_M, specifying --force-arch during
>> rootfs construction is all very well but they might still lose during a
>> subsequent "opkg upgrade".  So for these use cases, it seems as though
>> something a bit more sticky might be required.
>
> In terms of a proper solution I agree with this - opkg needs to handle the
> package architecture configuration internally rather than us overriding it at
> rootfs construction time. If you're advocating spending effort implementing
> something I think that's where it should be spent.
>
> Cheers,
> Paul
>