[OE-core] [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

Ming Liu ming.liu at windriver.com
Wed Apr 9 06:41:23 UTC 2014


On 04/08/2014 06:03 PM, Richard Purdie wrote:
> On Tue, 2014-04-08 at 10:27 +0800, Ming Liu wrote:
>> On 04/07/2014 07:36 PM, Richard Purdie wrote:
>>> On Mon, 2014-04-07 at 19:27 +0800, Ming Liu wrote:
>>>> In most cases binconfig files conflict among multilib packages, to avoid
>>>> that, use update-alternatives link *-config from real path with a
>>>> PACKAGE_ARCH suffix.
>>>>
>>>> Signed-off-by: Ming Liu <ming.liu at windriver.com>
>>>> ---
>>>>    meta/classes/binconfig.bbclass | 65 ++++++++++++++++++++++++++++++++++++------
>>>>    1 file changed, 56 insertions(+), 9 deletions(-)
>>> This isn't going in, its complex and supports a minority use case.
>>> binconfig should be dying out, not being extended and shored up like
>>> this.
>>>
>>> I'd also add this patch is buggy, its pure luck that update-alternatives
>>> is available at rootfs generation time since its not in a visible
>>> dependency.
>>>
>>> So going forward I'd like to see patches which simply delete binconfig
>>> scripts. Where there isn't a .pc alternative we should be adding them
>>> and pushing them upstream.
>> Did you mean we'd better remove all *-config scripts, insteaded by
>> providing .pc files, and send the changes to all upstreams providing and
>> using *-config? That seems a huge work and we need co-operate with a lot
>> of projects.
> Basically, yes, that is what I mean. I might be wrong but I don't think
> there are that many projects which don't ship .pc files now and just
> have a binconfig as a backup.
Yes, I also noticed that many of them are providing .pc files as well as 
binconfig as a backup, so I think there must be reasons binconfig 
remained in their projects, that might be for compliable considering,  
so I am not sure they would like to remove them from their projects, but 
I can try to ping them. Nevertheless, the conflicts still exist, we just 
leave them here so far?

//Ming Liu
>
> Cheers,
>
> Richard
>
>
>
>




More information about the Openembedded-core mailing list