On Wed, 2014-04-09 at 18:01 +0800, 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 <[email protected]> > >>>>>> --- > >>>>>> 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.
Agreed, I'm not asking you personally to do all of this, just suggesting that ultimately this is the route we need to take. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
