From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by mail.openembedded.org (Postfix) with ESMTP id 5C8336100E for ; Thu, 12 Sep 2013 07:24:02 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.5/8.14.3) with ESMTP id r8C7O2QG010513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 00:24:02 -0700 (PDT) Received: from [128.224.162.224] (128.224.162.224) by ALA-HCA.corp.ad.wrs.com (147.11.189.40) with Microsoft SMTP Server id 14.2.347.0; Thu, 12 Sep 2013 00:24:01 -0700 Message-ID: <52316C02.7090607@windriver.com> Date: Thu, 12 Sep 2013 15:23:46 +0800 From: Robert Yang User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Richard Purdie References: <1378736079.3484.117.camel@ted> In-Reply-To: <1378736079.3484.117.camel@ted> Cc: openembedded-core Subject: Re: [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 07:24:02 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I've done a world build on qemux86 with: PROVIDES_prepend = "${PN} " it worked well. // Robert On 09/09/2013 10:14 PM, Richard Purdie wrote: > For a long time we've provided PN-PV and PN-PV-PR by tweaking PROVIDES. This looks > nice at first glance however it turns out to be a bit problematic. Taking make as an > example where there are two versions, 3.81 and 3.82, what should "bitbake make-3.81" do? > > Currently it builds make-3.81 and make-3.82 and breaks in interesting ways. Is that > a bitbake bug? Well, it certainly shouldn't try and run the build. Why is it building > 3.82 though? Its due to finding a dependency on "make-dev" and then trying to figure > out what provides it? The answer is "make" and the default version of "make" is 3.82. > > So arguably, finding "make-3.81" should infer PREFERRED_VERSION_make = "3.81". Doing > so resolved the above problem since now "make" resolves to "make-3.81". > > So what about if we have Recipe A: > DEPENDS = "make-3.81" > and Recipe B: > DEPENDS = "make-3.82" > > That is clearly an error, easy. So finally what about if we have Recipe A: > DEPENDS = "make-3.81" > and Recipe B: > DEPENDS = "make" > > The first recipe infers the PREFERRED_VERSION_make = "3.81" and then forces that > version on everything else. Is that desired? Probably not in most cases, at least not > silently. > > As mitigation, we could print a WARNING about this happening. The final part of the problem > is that we can ony figure this out within bitbake itself. That means we'd have to teach bitbake > about the PN-PV format of PROVIDES which is breaking the separation between bitbake and the > metadata. We can't win :(. > > Nobody that I know of is using or relying on this functionality so perhaps we should > just remove it instead which is what this patch does. Opinions? > > Signed-off-by: Richard Purdie > --- > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > index 2d19d86..578c7d0 100644 > --- a/meta/conf/bitbake.conf > +++ b/meta/conf/bitbake.conf > @@ -253,7 +253,7 @@ DEPCHAIN_POST = "-dev -dbg" > DEPENDS = "" > RDEPENDS = "" > PROVIDES = "" > -PROVIDES_prepend = "${P} ${PF} ${PN} " > +PROVIDES_prepend = "${PN} " > RPROVIDES = "" > > MULTI_PROVIDER_WHITELIST = "virtual/libintl virtual/libintl-native virtual/nativesdk-libintl virtual/xserver virtual/update-alternatives-native virtual/update-alternatives" > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > >