Re: [PATCH 3/3] binconfig.bbclass: fix multilib file conflicts

[Ming Liu <ming.liu@windriver.com>]

On 04/09/2014 05:42 PM, Richard Purdie wrote:
> On Wed, 2014-04-09 at 14:41 +0800, Ming Liu wrote:
>> 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@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?
> I'm thinking we should start deleting the -config files at do_install
> time where we know a good .pc file exists and remove the binconfig
> inherit. If this causes any problem in software using the package, we
> should fix those to use pkgconfig.
>
> Over time the conflicts will stop existing since the binconfig class
> will not be used anywhere.
Yes, that's a feasible solution, but it needs a lot of testing works, 
unfortunately, I am a little busy with my daily work recently and cant 
handle it parallelly, so I'd like to file a bug in Yocto, see if anybody 
like to take it, or I will do it when I can tear myself away from work 
later.

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