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

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

On 04/09/2014 06:01 PM, Ming Liu wrote:
> 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.
Seems we already have the defect record, and Qi Chen has been working on 
that for a while, see the following:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2453

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