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

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

On Wed, 2014-04-09 at 18:07 +0800, Ming Liu wrote:
> 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

That bug suggests we have .pc files for all -config files. We would
therefore next need to follow through and remove all the -config files
entirely and just rely on the .pc files. We should open an enhancement
request for that.

Cheers,

Richard