All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][PATCH] qt-creator: avoid conflicts with meta-qt5's qt5-creator
Date: Thu, 5 Mar 2015 22:32:07 +0100	[thread overview]
Message-ID: <20150305213207.GA2337@jama> (raw)
In-Reply-To: <CALbNGRSb40o4eW=keqYx+3Ty04f-DHPj53h9bysC_WfhxgG_gA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3142 bytes --]

On Thu, Mar 05, 2015 at 09:57:37PM +0100, Andreas Müller wrote:
> On Thu, Mar 5, 2015 at 7:01 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Sun, Mar 01, 2015 at 11:23:44PM +0100, Andreas Müller wrote:
> >> We avoid conflicts by installing no files to sysroot. This causes no fallout
> >> because nothing depends on qt5-creator (if something included later depending
> >> on qt-creator it should depend on qt5-creator).
> >> Note that
> >>
> >> | WARNING: QA Issue: qt5-creator rdepends on qt-creator, but it isn't a build dependency? [build-deps]
> >>
> >> is a false positve because the names of the libraries are same as for
> >> qt5-creator (see test below).
> >
> > This isn't enough to resolve the warning (but it resolves the sysroot
> > conflict which is good).
> >
> > qt-creator is still recorded as runtime provider for couple of
> > libraries, we can list them all in PRIVATE_LIBS (if we can assume that
> > nothing will link against them - which is already assumed by not staging
> > them).
> >
> > Here is the list from qt5-creator log.do_package:
> >
> > $ grep "requires package qt-creator" log.do_package
> > DEBUG: qt5-creator: Dependency libCore.so requires package qt-creator (used by files: /home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5e-oe-linux-gnueabi/qt5-creator/3.3.1-r0/packages-split/qt5-creator/usr/lib/qt5/qtcreator/plugins/libQmlJSTools.so)
> Very interesting:
> 
> * qt5-creator complains for libs it has installed itself (see qt5 in path)
> * how should someone link against libraries that are not in sysroot?

See the code for shlibs providers in package.bbclass, this warning and
this whole issue originates there.

shlibs providers record all installed libraries (not staged in sysroot),
so that it can automatically add RDEPENDS in case some other package
will require already found library.

This happens with qt*-creators, there are plans to improve it by
including the whole path, but that doesn't work yet with current
package.bbclass.

> * during my tests for sysroot patch I have build qt-creator from
> scratch and then an image with qt5-creator included. If this warning
> would be true the image creation would have failed because qt5-creator
> RCONFLICTS qt-creator (error occured when starting the last patch)
> 
> Problem seems that that the instance creating (have not looked
> further) these warnings just checks the name of the library without
> path. Library names are same for both versions of qt-creator.
> 
> We could try it with PRIVATE_LIBS but I'd suggest to simply ignore
> these false warnings.

I was suggesting PRIVATE_LIBS because it sort of matches with skipping
the staging of the libraries.

The warning is still valid in cases when someone builds qt-creator
first, then qt5-creator which will automatically get RDEPENDS on
qt-creator, so installing qt5-creator from package feed will bring both
of them :(.

If we set PRIVATE_LIBS in qt-creator, it won't ever be registered as
shlib provider, so qt5-creator won't get the RDEPENDS.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

      reply	other threads:[~2015-03-05 21:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-01 22:23 [meta-oe][PATCH] qt-creator: avoid conflicts with meta-qt5's qt5-creator Andreas Müller
2015-03-05 18:01 ` Martin Jansa
2015-03-05 20:57   ` Andreas Müller
2015-03-05 21:32     ` Martin Jansa [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150305213207.GA2337@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.