[v3] dbus: include dbus-launch in the main dbus package

Submitted by Radu Moisan on July 26, 2012, 6:17 a.m.

Details

Message ID 1343283462-25435-1-git-send-email-radu.moisan@intel.com
State New
Headers show

Commit Message

Radu Moisan July 26, 2012, 6:17 a.m.
Followed suggestions from Bugz 2261:

1) remove the --with-x/--without-x configure arguments. If you want to force
no-discovery for native builds the correct argument is --disable-x11-autolaunch.
This ensures that DBus looks at the build environment to determine whether to
enable X11 bus discovery or not.

2) make the virtual/libx11 DEPENDS conditional based on the x11 distro feature.
This makes the build dependencies reflect the feature list.

3) remove dbus-x11, meaning that dbus-launch with its potential X11 dependency
is now back in dbus where is belongs.

4) Potentially make dbus provide dbus-x11, for compatibility.

Fixes [Yocto #2261]

Signed-off-by: Radu Moisan <radu.moisan@intel.com>
---
 meta/recipes-core/dbus/dbus.inc |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

Patch hide | download patch | download mbox

diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index a75583d..9559f6f 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -31,10 +31,10 @@  CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session
 
 DEBIANNAME_${PN} = "dbus-1"
 
-PACKAGES =+ "${PN}-lib ${PN}-systemd ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}"
+PACKAGES =+ "${PN}-lib ${PN}-systemd"
 
-FILES_${PN}-x11 = "${bindir}/dbus-launch"
-RDEPENDS_${PN}-x11 = "${PN}"
+# for compatibility
+RREPLACES_${PN} += "dbus-x11"
 
 FILES_${PN}-systemd = "${systemd_unitdir}/system/"
 
@@ -43,6 +43,7 @@  FILES_${PN} = "${bindir}/dbus-daemon* \
                ${bindir}/dbus-cleanup-sockets \
                ${bindir}/dbus-send \
                ${bindir}/dbus-monitor \
+               ${bindir}/dbus-launch \
                ${libexecdir}/dbus* \
                ${sysconfdir} \
                ${localstatedir} \
@@ -58,8 +59,8 @@  pkg_postinst_dbus() {
 	fi
 }
 
-EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', '--without-x', d)}"
-EXTRA_OECONF_X_virtclass-native = "--without-x"
+EXTRA_OECONF_X = ""
+EXTRA_OECONF_X_virtclass-native = "--disable-x11-autolaunch"
 
 EXTRA_OECONF = "--disable-tests \
                 --disable-checks \

Comments

Radu Moisan July 26, 2012, 6:29 a.m.
it does not build, it complains about nothing providing dbus-x11

Radu

On 07/26/2012 09:17 AM, Radu Moisan wrote:
> Followed suggestions from Bugz 2261:
>
> 1) remove the --with-x/--without-x configure arguments. If you want to force
> no-discovery for native builds the correct argument is --disable-x11-autolaunch.
> This ensures that DBus looks at the build environment to determine whether to
> enable X11 bus discovery or not.
>
> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro feature.
> This makes the build dependencies reflect the feature list.
>
> 3) remove dbus-x11, meaning that dbus-launch with its potential X11 dependency
> is now back in dbus where is belongs.
>
> 4) Potentially make dbus provide dbus-x11, for compatibility.
>
> Fixes [Yocto #2261]
>
> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
> ---
>   meta/recipes-core/dbus/dbus.inc |   11 ++++++-----
>   1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
> index a75583d..9559f6f 100644
> --- a/meta/recipes-core/dbus/dbus.inc
> +++ b/meta/recipes-core/dbus/dbus.inc
> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session
>   
>   DEBIANNAME_${PN} = "dbus-1"
>   
> -PACKAGES =+ "${PN}-lib ${PN}-systemd ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}"
> +PACKAGES =+ "${PN}-lib ${PN}-systemd"
>   
> -FILES_${PN}-x11 = "${bindir}/dbus-launch"
> -RDEPENDS_${PN}-x11 = "${PN}"
> +# for compatibility
> +RREPLACES_${PN} += "dbus-x11"
>   
>   FILES_${PN}-systemd = "${systemd_unitdir}/system/"
>   
> @@ -43,6 +43,7 @@ FILES_${PN} = "${bindir}/dbus-daemon* \
>                  ${bindir}/dbus-cleanup-sockets \
>                  ${bindir}/dbus-send \
>                  ${bindir}/dbus-monitor \
> +               ${bindir}/dbus-launch \
>                  ${libexecdir}/dbus* \
>                  ${sysconfdir} \
>                  ${localstatedir} \
> @@ -58,8 +59,8 @@ pkg_postinst_dbus() {
>   	fi
>   }
>   
> -EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', '--without-x', d)}"
> -EXTRA_OECONF_X_virtclass-native = "--without-x"
> +EXTRA_OECONF_X = ""
> +EXTRA_OECONF_X_virtclass-native = "--disable-x11-autolaunch"
>   
>   EXTRA_OECONF = "--disable-tests \
>                   --disable-checks \
Koen Kooi July 26, 2012, 8:08 a.m.
Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het volgende geschreven:

> it does not build, it complains about nothing providing dbus-x11
> 
> Radu
> 
> On 07/26/2012 09:17 AM, Radu Moisan wrote:
>> Followed suggestions from Bugz 2261:
>> 
>> 1) remove the --with-x/--without-x configure arguments. If you want to force
>> no-discovery for native builds the correct argument is --disable-x11-autolaunch.
>> This ensures that DBus looks at the build environment to determine whether to
>> enable X11 bus discovery or not.
>> 
>> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro feature.
>> This makes the build dependencies reflect the feature list.
>> 
>> 3) remove dbus-x11, meaning that dbus-launch with its potential X11 dependency
>> is now back in dbus where is belongs.
>> 
>> 4) Potentially make dbus provide dbus-x11, for compatibility.
>> 
>> Fixes [Yocto #2261]
>> 
>> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
>> ---
>>  meta/recipes-core/dbus/dbus.inc |   11 ++++++-----
>>  1 file changed, 6 insertions(+), 5 deletions(-)
>> 
>> diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
>> index a75583d..9559f6f 100644
>> --- a/meta/recipes-core/dbus/dbus.inc
>> +++ b/meta/recipes-core/dbus/dbus.inc
>> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session
>>    DEBIANNAME_${PN} = "dbus-1"
>>  -PACKAGES =+ "${PN}-lib ${PN}-systemd ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}"
>> +PACKAGES =+ "${PN}-lib ${PN}-systemd"
>>  -FILES_${PN}-x11 = "${bindir}/dbus-launch"
>> -RDEPENDS_${PN}-x11 = "${PN}"
>> +# for compatibility

PROVIDES += "dbus-x11"

>> +RREPLACES_${PN} += "dbus-x11"

RPROVIDES_${PN} += "dbus-x11"
Paul Eggleton July 26, 2012, 8:42 a.m.
On Thursday 26 July 2012 10:08:49 Koen Kooi wrote:
> Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het
> > volgende geschreven:
> > it does not build, it complains about nothing providing dbus-x11
> > 
> > Radu
> > 
> > On 07/26/2012 09:17 AM, Radu Moisan wrote:
> >> Followed suggestions from Bugz 2261:
> >> 
> >> 1) remove the --with-x/--without-x configure arguments. If you want to
> >> force no-discovery for native builds the correct argument is
> >> --disable-x11-autolaunch. This ensures that DBus looks at the build
> >> environment to determine whether to enable X11 bus discovery or not.
> >> 
> >> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro
> >> feature. This makes the build dependencies reflect the feature list.
> >> 
> >> 3) remove dbus-x11, meaning that dbus-launch with its potential X11
> >> dependency is now back in dbus where is belongs.
> >> 
> >> 4) Potentially make dbus provide dbus-x11, for compatibility.
> >> 
> >> Fixes [Yocto #2261]
> >> 
> >> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
> >> ---
> >> 
> >>  meta/recipes-core/dbus/dbus.inc |   11 ++++++-----
> >>  1 file changed, 6 insertions(+), 5 deletions(-)
> >> 
> >> diff --git a/meta/recipes-core/dbus/dbus.inc
> >> b/meta/recipes-core/dbus/dbus.inc index a75583d..9559f6f 100644
> >> --- a/meta/recipes-core/dbus/dbus.inc
> >> +++ b/meta/recipes-core/dbus/dbus.inc
> >> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf
> >> ${sysconfdir}/dbus-1/session>> 
> >>    DEBIANNAME_${PN} = "dbus-1"
> >>  
> >>  -PACKAGES =+ "${PN}-lib ${PN}-systemd
> >>  ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}">> 
> >> +PACKAGES =+ "${PN}-lib ${PN}-systemd"
> >> 
> >>  -FILES_${PN}-x11 = "${bindir}/dbus-launch"
> >> 
> >> -RDEPENDS_${PN}-x11 = "${PN}"
> >> +# for compatibility
> 
> PROVIDES += "dbus-x11"
> 
> >> +RREPLACES_${PN} += "dbus-x11"
> 
> RPROVIDES_${PN} += "dbus-x11"

For the sake of clarity, you mean both of these, not RPROVIDES instead of 
adding RREPLACES - right?

Cheers,
Paul
Koen Kooi July 26, 2012, 8:43 a.m.
Op 26 jul. 2012, om 10:42 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Thursday 26 July 2012 10:08:49 Koen Kooi wrote:
>> Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het
>>> volgende geschreven:
>>> it does not build, it complains about nothing providing dbus-x11
>>> 
>>> Radu
>>> 
>>> On 07/26/2012 09:17 AM, Radu Moisan wrote:
>>>> Followed suggestions from Bugz 2261:
>>>> 
>>>> 1) remove the --with-x/--without-x configure arguments. If you want to
>>>> force no-discovery for native builds the correct argument is
>>>> --disable-x11-autolaunch. This ensures that DBus looks at the build
>>>> environment to determine whether to enable X11 bus discovery or not.
>>>> 
>>>> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro
>>>> feature. This makes the build dependencies reflect the feature list.
>>>> 
>>>> 3) remove dbus-x11, meaning that dbus-launch with its potential X11
>>>> dependency is now back in dbus where is belongs.
>>>> 
>>>> 4) Potentially make dbus provide dbus-x11, for compatibility.
>>>> 
>>>> Fixes [Yocto #2261]
>>>> 
>>>> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
>>>> ---
>>>> 
>>>> meta/recipes-core/dbus/dbus.inc |   11 ++++++-----
>>>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>>> 
>>>> diff --git a/meta/recipes-core/dbus/dbus.inc
>>>> b/meta/recipes-core/dbus/dbus.inc index a75583d..9559f6f 100644
>>>> --- a/meta/recipes-core/dbus/dbus.inc
>>>> +++ b/meta/recipes-core/dbus/dbus.inc
>>>> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf
>>>> ${sysconfdir}/dbus-1/session>> 
>>>>   DEBIANNAME_${PN} = "dbus-1"
>>>> 
>>>> -PACKAGES =+ "${PN}-lib ${PN}-systemd
>>>> ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}">> 
>>>> +PACKAGES =+ "${PN}-lib ${PN}-systemd"
>>>> 
>>>> -FILES_${PN}-x11 = "${bindir}/dbus-launch"
>>>> 
>>>> -RDEPENDS_${PN}-x11 = "${PN}"
>>>> +# for compatibility
>> 
>> PROVIDES += "dbus-x11"
>> 
>>>> +RREPLACES_${PN} += "dbus-x11"
>> 
>> RPROVIDES_${PN} += "dbus-x11"
> 
> For the sake of clarity, you mean both of these, not RPROVIDES instead of 
> adding RREPLACES - right?

Correct, you need both (or rather all 3 if you include PROVIDES).
Radu Moisan July 26, 2012, 9:18 a.m.
What's the point of PROVIDES += dbus-x11, it build fine without it (I'm 
not questioning the correctness of this, just want to understand the 
need for it).

Radu

On 07/26/2012 11:43 AM, Koen Kooi wrote:
> Op 26 jul. 2012, om 10:42 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:
>
>> On Thursday 26 July 2012 10:08:49 Koen Kooi wrote:
>>> Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het
>>>> volgende geschreven:
>>>> it does not build, it complains about nothing providing dbus-x11
>>>>
>>>> Radu
>>>>
>>>> On 07/26/2012 09:17 AM, Radu Moisan wrote:
>>>>> Followed suggestions from Bugz 2261:
>>>>>
>>>>> 1) remove the --with-x/--without-x configure arguments. If you want to
>>>>> force no-discovery for native builds the correct argument is
>>>>> --disable-x11-autolaunch. This ensures that DBus looks at the build
>>>>> environment to determine whether to enable X11 bus discovery or not.
>>>>>
>>>>> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro
>>>>> feature. This makes the build dependencies reflect the feature list.
>>>>>
>>>>> 3) remove dbus-x11, meaning that dbus-launch with its potential X11
>>>>> dependency is now back in dbus where is belongs.
>>>>>
>>>>> 4) Potentially make dbus provide dbus-x11, for compatibility.
>>>>>
>>>>> Fixes [Yocto #2261]
>>>>>
>>>>> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
>>>>> ---
>>>>>
>>>>> meta/recipes-core/dbus/dbus.inc |   11 ++++++-----
>>>>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/meta/recipes-core/dbus/dbus.inc
>>>>> b/meta/recipes-core/dbus/dbus.inc index a75583d..9559f6f 100644
>>>>> --- a/meta/recipes-core/dbus/dbus.inc
>>>>> +++ b/meta/recipes-core/dbus/dbus.inc
>>>>> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf
>>>>> ${sysconfdir}/dbus-1/session>>
>>>>>    DEBIANNAME_${PN} = "dbus-1"
>>>>>
>>>>> -PACKAGES =+ "${PN}-lib ${PN}-systemd
>>>>> ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}">>
>>>>> +PACKAGES =+ "${PN}-lib ${PN}-systemd"
>>>>>
>>>>> -FILES_${PN}-x11 = "${bindir}/dbus-launch"
>>>>>
>>>>> -RDEPENDS_${PN}-x11 = "${PN}"
>>>>> +# for compatibility
>>> PROVIDES += "dbus-x11"
>>>
>>>>> +RREPLACES_${PN} += "dbus-x11"
>>> RPROVIDES_${PN} += "dbus-x11"
>> For the sake of clarity, you mean both of these, not RPROVIDES instead of
>> adding RREPLACES - right?
> Correct, you need both (or rather all 3 if you include PROVIDES).
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Koen Kooi July 26, 2012, 9:51 a.m.
Op 26 jul. 2012, om 11:18 heeft Radu Moisan het volgende geschreven:

> What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not questioning the correctness of this, just want to understand the need for it).

This morning you said:

"it does not build, it complains about nothing providing dbus-x11"

That's what the PROVIDES is for.


> 
> Radu
> 
> On 07/26/2012 11:43 AM, Koen Kooi wrote:
>> Op 26 jul. 2012, om 10:42 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:
>> 
>>> On Thursday 26 July 2012 10:08:49 Koen Kooi wrote:
>>>> Op 26 jul. 2012, om 08:29 heeft Radu Moisan <radu.moisan@intel.com> het
>>>>> volgende geschreven:
>>>>> it does not build, it complains about nothing providing dbus-x11
>>>>> 
>>>>> Radu
>>>>> 
>>>>> On 07/26/2012 09:17 AM, Radu Moisan wrote:
>>>>>> Followed suggestions from Bugz 2261:
>>>>>> 
>>>>>> 1) remove the --with-x/--without-x configure arguments. If you want to
>>>>>> force no-discovery for native builds the correct argument is
>>>>>> --disable-x11-autolaunch. This ensures that DBus looks at the build
>>>>>> environment to determine whether to enable X11 bus discovery or not.
>>>>>> 
>>>>>> 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro
>>>>>> feature. This makes the build dependencies reflect the feature list.
>>>>>> 
>>>>>> 3) remove dbus-x11, meaning that dbus-launch with its potential X11
>>>>>> dependency is now back in dbus where is belongs.
>>>>>> 
>>>>>> 4) Potentially make dbus provide dbus-x11, for compatibility.
>>>>>> 
>>>>>> Fixes [Yocto #2261]
>>>>>> 
>>>>>> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
>>>>>> ---
>>>>>> 
>>>>>> meta/recipes-core/dbus/dbus.inc |   11 ++++++-----
>>>>>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>>>>> 
>>>>>> diff --git a/meta/recipes-core/dbus/dbus.inc
>>>>>> b/meta/recipes-core/dbus/dbus.inc index a75583d..9559f6f 100644
>>>>>> --- a/meta/recipes-core/dbus/dbus.inc
>>>>>> +++ b/meta/recipes-core/dbus/dbus.inc
>>>>>> @@ -31,10 +31,10 @@ CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf
>>>>>> ${sysconfdir}/dbus-1/session>>
>>>>>>   DEBIANNAME_${PN} = "dbus-1"
>>>>>> 
>>>>>> -PACKAGES =+ "${PN}-lib ${PN}-systemd
>>>>>> ${@base_contains('DISTRO_FEATURES', 'x11', '${PN}-x11', '', d)}">>
>>>>>> +PACKAGES =+ "${PN}-lib ${PN}-systemd"
>>>>>> 
>>>>>> -FILES_${PN}-x11 = "${bindir}/dbus-launch"
>>>>>> 
>>>>>> -RDEPENDS_${PN}-x11 = "${PN}"
>>>>>> +# for compatibility
>>>> PROVIDES += "dbus-x11"
>>>> 
>>>>>> +RREPLACES_${PN} += "dbus-x11"
>>>> RPROVIDES_${PN} += "dbus-x11"
>>> For the sake of clarity, you mean both of these, not RPROVIDES instead of
>>> adding RREPLACES - right?
>> Correct, you need both (or rather all 3 if you include PROVIDES).
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Ross Burton July 26, 2012, 10:23 a.m.
On 26 July 2012 10:51, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not questioning the correctness of this, just want to understand the need for it).
>
> This morning you said:
>
> "it does not build, it complains about nothing providing dbus-x11"
>
> That's what the PROVIDES is for.

Without seeing the logs, I expect the error was when building the
image.  Nothing will build-depend on dbus-x11 because it isn't a
source package.

Radu, as a follow-up patch please remove all instances of dbus-x11,
replacing with dbus if required.

Ross
Radu Moisan July 26, 2012, 10:31 a.m.
the build issue was solved by RPROVIDES, while PROVIDES did not fix the 
build or influence the error in any way.

Radu

On 07/26/2012 12:51 PM, Koen Kooi wrote:
> Op 26 jul. 2012, om 11:18 heeft Radu Moisan het volgende geschreven:
>
>> What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not questioning the correctness of this, just want to understand the need for it).
> This morning you said:
>
> "it does not build, it complains about nothing providing dbus-x11"
>
> That's what the PROVIDES is for.
>
Radu Moisan July 26, 2012, 10:36 a.m.
should I create a single patch that changes dbus-x11 to dbus, or one for 
each package?

Radu

On 07/26/2012 01:23 PM, Burton, Ross wrote:
> On 26 July 2012 10:51, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>> What's the point of PROVIDES += dbus-x11, it build fine without it (I'm not questioning the correctness of this, just want to understand the need for it).
>> This morning you said:
>>
>> "it does not build, it complains about nothing providing dbus-x11"
>>
>> That's what the PROVIDES is for.
> Without seeing the logs, I expect the error was when building the
> image.  Nothing will build-depend on dbus-x11 because it isn't a
> source package.
>
> Radu, as a follow-up patch please remove all instances of dbus-x11,
> replacing with dbus if required.
>
> Ross
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Radu Moisan July 26, 2012, 10:55 a.m.
I see no build-time dependencies on dbus-x11 (only runtime 
dependencies), so, assuming PROVIDES is used at build-time, I don't see 
it's point.

Radu

On 07/26/2012 01:31 PM, Radu Moisan wrote:
> the build issue was solved by RPROVIDES, while PROVIDES did not fix 
> the build or influence the error in any way.
>
> Radu
>
> On 07/26/2012 12:51 PM, Koen Kooi wrote:
>> Op 26 jul. 2012, om 11:18 heeft Radu Moisan het volgende geschreven:
>>
>>> What's the point of PROVIDES += dbus-x11, it build fine without it 
>>> (I'm not questioning the correctness of this, just want to 
>>> understand the need for it).
>> This morning you said:
>>
>> "it does not build, it complains about nothing providing dbus-x11"
>>
>> That's what the PROVIDES is for.
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Ross Burton July 26, 2012, 11:27 a.m.
On 26 July 2012 11:55, Radu Moisan <radu.moisan@intel.com> wrote:
> I see no build-time dependencies on dbus-x11 (only runtime dependencies),
> so, assuming PROVIDES is used at build-time, I don't see it's point.

We've just removed dbus-x11 because it's pointless, the provides is
only for compatibility.

Ross
Koen Kooi July 26, 2012, 11:55 a.m.
Op 26 jul. 2012, om 13:27 heeft Burton, Ross het volgende geschreven:

> On 26 July 2012 11:55, Radu Moisan <radu.moisan@intel.com> wrote:
>> I see no build-time dependencies on dbus-x11 (only runtime dependencies),
>> so, assuming PROVIDES is used at build-time, I don't see it's point.
> 
> We've just removed dbus-x11 because it's pointless, the provides is
> only for compatibility.

It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep working till their maintainers get around fixing them. Note that you might need to do a -c cleansstate on dbus first to trigger any errors.
Ross Burton July 26, 2012, noon
On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote:
> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep working till their maintainers get around fixing them. Note that you might need to do a -c cleansstate on dbus first to trigger any errors.

Yes, and isn't that what the RPROVIDES is for?

Ross
Koen Kooi July 26, 2012, 12:29 p.m.
Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven:

> On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep working till their maintainers get around fixing them. Note that you might need to do a -c cleansstate on dbus first to trigger any errors.
> 
> Yes, and isn't that what the RPROVIDES is for?

I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember that it doesn't, but it will pick it up *after* do_package has run. I broke OE way too many times doing things like that :)
Paul Eggleton July 26, 2012, 12:32 p.m.
On Thursday 26 July 2012 14:29:14 Koen Kooi wrote:
> Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven:
> > On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep
> >> working till their maintainers get around fixing them. Note that you
> >> might need to do a -c cleansstate on dbus first to trigger any errors.> 
> > Yes, and isn't that what the RPROVIDES is for?
> 
> I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember
> that it doesn't, but it will pick it up *after* do_package has run. I broke
> OE way too many times doing things like that :)

Why would it need to if we're talking about RDEPENDS and more specifically 
RDEPENDS defined before do_package?

Cheers,
Paul
Koen Kooi July 26, 2012, 12:38 p.m.
Op 26 jul. 2012, om 14:32 heeft Paul Eggleton het volgende geschreven:

> On Thursday 26 July 2012 14:29:14 Koen Kooi wrote:
>> Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven:
>>> On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep
>>>> working till their maintainers get around fixing them. Note that you
>>>> might need to do a -c cleansstate on dbus first to trigger any errors.> 
>>> Yes, and isn't that what the RPROVIDES is for?
>> 
>> I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember
>> that it doesn't, but it will pick it up *after* do_package has run. I broke
>> OE way too many times doing things like that :)
> 
> Why would it need to if we're talking about RDEPENDS and more specifically 
> RDEPENDS defined before do_package?

Because AIUI RDEPENDS get resolved to build the runqueue, so you can't do RDEPENDS_foo = "I-don't-exist". If that's not the case I'll shut up :)

regards,

Koen
Koen Kooi July 26, 2012, 12:51 p.m.
Op 26 jul. 2012, om 14:36 heeft Radu Moisan het volgende geschreven:

> I understand the reasoning behind RPROVIDES. I've grep'ed the sources and none of the packages that depend on dbus-x11 have build time dependencies on it, 

You grepped all the layers out there for 'dbus-x11' or only oe-core?
Paul Eggleton July 26, 2012, 12:56 p.m.
On Thursday 26 July 2012 14:38:59 Koen Kooi wrote:
> Op 26 jul. 2012, om 14:32 heeft Paul Eggleton het volgende geschreven:
> > On Thursday 26 July 2012 14:29:14 Koen Kooi wrote:
> >> Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven:
> >>> On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >>>> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11"
> >>>> keep
> >>>> working till their maintainers get around fixing them. Note that you
> >>>> might need to do a -c cleansstate on dbus first to trigger any errors.>
> >>> 
> >>> Yes, and isn't that what the RPROVIDES is for?
> >> 
> >> I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember
> >> that it doesn't, but it will pick it up *after* do_package has run. I
> >> broke
> >> OE way too many times doing things like that :)
> > 
> > Why would it need to if we're talking about RDEPENDS and more specifically
> > RDEPENDS defined before do_package?
> 
> Because AIUI RDEPENDS get resolved to build the runqueue, so you can't do
> RDEPENDS_foo = "I-don't-exist". If that's not the case I'll shut up :)

Without being too concerned with implementation details, I think it's as 
simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo in 
RPROVIDES_${PN} then the runtime dependency is considered satisfied and things 
will work. You don't have to specify foo in PROVIDES unless something else has 
foo in DEPENDS.

Cheers,
Paul
Radu Moisan July 26, 2012, 12:59 p.m.
only in meta & meta-intel.

Radu

On 07/26/2012 03:51 PM, Koen Kooi wrote:
> Op 26 jul. 2012, om 14:36 heeft Radu Moisan het volgende geschreven:
>
>> I understand the reasoning behind RPROVIDES. I've grep'ed the sources and none of the packages that depend on dbus-x11 have build time dependencies on it,
> You grepped all the layers out there for 'dbus-x11' or only oe-core?
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Radu Moisan July 26, 2012, 1:06 p.m.
This was also my understanding. Ok so we want PROVIDES in there just for 
the case in which someone in some layer created a dependency on dbus-x11 
(in some recipe) with DEPENDS and we don't want to break his build - 
this argument will suffice, as far as I am concerned.

Radu


On 07/26/2012 03:56 PM, Paul Eggleton wrote:
>
> Without being too concerned with implementation details, I think it's as
> simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo in
> RPROVIDES_${PN} then the runtime dependency is considered satisfied and things
> will work. You don't have to specify foo in PROVIDES unless something else has
> foo in DEPENDS.
>
> Cheers,
> Paul
>
Koen Kooi July 26, 2012, 1:07 p.m.
Op 26 jul. 2012, om 14:56 heeft Paul Eggleton het volgende geschreven:

> On Thursday 26 July 2012 14:38:59 Koen Kooi wrote:
>> Op 26 jul. 2012, om 14:32 heeft Paul Eggleton het volgende geschreven:
>>> On Thursday 26 July 2012 14:29:14 Koen Kooi wrote:
>>>> Op 26 jul. 2012, om 14:00 heeft Burton, Ross het volgende geschreven:
>>>>> On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>>>> It would be nice if other layers that have RDEPENDS_foo = "dbus-x11"
>>>>>> keep
>>>>>> working till their maintainers get around fixing them. Note that you
>>>>>> might need to do a -c cleansstate on dbus first to trigger any errors.>
>>>>> 
>>>>> Yes, and isn't that what the RPROVIDES is for?
>>>> 
>>>> I'm not sure if bitbake can map RPROVIDES to PROVIDES, I vaguely remember
>>>> that it doesn't, but it will pick it up *after* do_package has run. I
>>>> broke
>>>> OE way too many times doing things like that :)
>>> 
>>> Why would it need to if we're talking about RDEPENDS and more specifically
>>> RDEPENDS defined before do_package?
>> 
>> Because AIUI RDEPENDS get resolved to build the runqueue, so you can't do
>> RDEPENDS_foo = "I-don't-exist". If that's not the case I'll shut up :)
> 
> Without being too concerned with implementation details, I think it's as 
> simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo in 
> RPROVIDES_${PN} then the runtime dependency is considered satisfied and things 
> will work. You don't have to specify foo in PROVIDES unless something else has 
> foo in DEPENDS.

If that's so, great, but please check :)
Enrico Scholz July 26, 2012, 1:08 p.m.
Koen Kooi <koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org>
writes:

> RPROVIDES_${PN} += "dbus-x11"

This is wrong because 'dbus' does not provide dbus-x11 when x11 is
disabled by distro.  Packages which require dbus-launch from 'dbus-x11'
will install fine but will fail at runtime.


Enrico
Paul Eggleton July 26, 2012, 1:12 p.m.
On Thursday 26 July 2012 15:07:42 Koen Kooi wrote:
> > Without being too concerned with implementation details, I think it's as
> > simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo
> > in RPROVIDES_${PN} then the runtime dependency is considered satisfied
> > and things will work. You don't have to specify foo in PROVIDES unless
> > something else has foo in DEPENDS.
> 
> If that's so, great, but please check :)

I did, prior to sending that... :)

Cheers,
Paul
Enrico Scholz July 26, 2012, 1:17 p.m.
Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
writes:

> Followed suggestions from Bugz 2261:
>
> 1) remove the --with-x/--without-x configure arguments.

why? They are valid ./configure options and common when evaluating the
x11 distro-feature.  Selecting them explicitly makes the build more
predictable and detects configuration errors earlier.

Sense of '--without-x' was disabling of x11 dependency, but not turning
off the x11-autolaunch feature.


Enrico
Koen Kooi July 26, 2012, 1:21 p.m.
Op 26 jul. 2012, om 15:12 heeft Paul Eggleton het volgende geschreven:

> On Thursday 26 July 2012 15:07:42 Koen Kooi wrote:
>>> Without being too concerned with implementation details, I think it's as
>>> simple as this: if recipe A has foo in RDEPENDS_${PN} and recipe B has foo
>>> in RPROVIDES_${PN} then the runtime dependency is considered satisfied
>>> and things will work. You don't have to specify foo in PROVIDES unless
>>> something else has foo in DEPENDS.
>> 
>> If that's so, great, but please check :)
> 
> I did, prior to sending that... :)

great, I'll shut up now :)
Radu Moisan July 26, 2012, 1:24 p.m.
it does not crash at runtime. You can try

dbus-launch --auto-syntax

it'll start a bus and print out the information like:

DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-N48lpeD2TP,guid=0f3cd66fdbdc2f436a9356790002eaa1';
export DBUS_SESSION_BUS_ADDRESS;
DBUS_SESSION_BUS_PID=23640;

Radu

On 07/26/2012 04:08 PM, Enrico Scholz wrote:
> Koen Kooi <koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org>
> writes:
>
>> RPROVIDES_${PN} += "dbus-x11"
> This is wrong because 'dbus' does not provide dbus-x11 when x11 is
> disabled by distro.  Packages which require dbus-launch from 'dbus-x11'
> will install fine but will fail at runtime.
>
>
> Enrico
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Enrico Scholz July 26, 2012, 2:32 p.m.
Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
writes:

> it does not crash at runtime.

I do not speak about crash; I guess 'dbus-launch' has some extra
functionality when compiled with x11 support, and packages which
depend on dbus-x11 might expect this functionality.

Providing 'dbus-x11' although no x11 functionality is provided sounds
wrong to me.  Either remove the 'dbus-x11' property completely or provide
it only when x11 support is built in.


Enrico
Ross Burton July 26, 2012, 9:12 p.m.
On 26 July 2012 14:17, Enrico Scholz <enrico.scholz@sigma-chemnitz.de> wrote:
> Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> writes:
>
>> Followed suggestions from Bugz 2261:
>>
>> 1) remove the --with-x/--without-x configure arguments.
>
> why? They are valid ./configure options and common when evaluating the
> x11 distro-feature.  Selecting them explicitly makes the build more
> predictable and detects configuration errors earlier.
>
> Sense of '--without-x' was disabling of x11 dependency, but not turning
> off the x11-autolaunch feature.

That's my fault, and I can't remember my reasoning.  Probably best to
bring it back so the recipe is explicit.

Radu, bring back this fragment, but correct the options

EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11',
'--enable-x11-autolaunch', '--disable-x11-autolaunch', d)}"

Ross
Ross Burton July 26, 2012, 9:14 p.m.
On 26 July 2012 15:32, Enrico Scholz <enrico.scholz@sigma-chemnitz.de> wrote:
> I do not speak about crash; I guess 'dbus-launch' has some extra
> functionality when compiled with x11 support, and packages which
> depend on dbus-x11 might expect this functionality.
>
> Providing 'dbus-x11' although no x11 functionality is provided sounds
> wrong to me.  Either remove the 'dbus-x11' property completely or provide
> it only when x11 support is built in.

I disagree.  Currently dbus-launch is packaged in dbus-x11 which may
or may not have a dependency on X11.  *That* makes no sense.

Moving dbus-launch into dbus which conditionally has X11 autolaunch
support depending on whether X11 is being used or not makes sense to
me.

Ross
Radu Moisan July 27, 2012, 6:10 a.m.
On 07/27/2012 12:12 AM, Burton, Ross wrote:
> On 26 July 2012 14:17, Enrico Scholz <enrico.scholz@sigma-chemnitz.de> wrote:
>> Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> writes:
>>
>>> Followed suggestions from Bugz 2261:
>>>
>>> 1) remove the --with-x/--without-x configure arguments.
>> why? They are valid ./configure options and common when evaluating the
>> x11 distro-feature.  Selecting them explicitly makes the build more
>> predictable and detects configuration errors earlier.
>>
>> Sense of '--without-x' was disabling of x11 dependency, but not turning
>> off the x11-autolaunch feature.
> That's my fault, and I can't remember my reasoning.  Probably best to
> bring it back so the recipe is explicit.
>
> Radu, bring back this fragment, but correct the options
>
> EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11',
> '--enable-x11-autolaunch', '--disable-x11-autolaunch', d)}"
>
> Ross
>
I've looked into the configure script and found that autolaunch feature 
is depending on x11, in other words using --with-x/--without-x implies 
--enable-x11-autolaunch/--disable-x11-autolaunch, so I guess the initial 
EXTRA_OECONF_X line will do pretty much the same thing.

EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', 
'--without-x', d)}"

Radu
Radu Moisan July 27, 2012, 6:15 a.m.
On 07/27/2012 09:10 AM, Radu Moisan wrote:
>
> On 07/27/2012 12:12 AM, Burton, Ross wrote:
>> On 26 July 2012 14:17, Enrico Scholz<enrico.scholz@sigma-chemnitz.de>  wrote:
>>> Radu Moisan<radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>> writes:
>>>
>>>> Followed suggestions from Bugz 2261:
>>>>
>>>> 1) remove the --with-x/--without-x configure arguments.
>>> why? They are valid ./configure options and common when evaluating the
>>> x11 distro-feature.  Selecting them explicitly makes the build more
>>> predictable and detects configuration errors earlier.
>>>
>>> Sense of '--without-x' was disabling of x11 dependency, but not turning
>>> off the x11-autolaunch feature.
>> That's my fault, and I can't remember my reasoning.  Probably best to
>> bring it back so the recipe is explicit.
>>
>> Radu, bring back this fragment, but correct the options
>>
>> EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11',
>> '--enable-x11-autolaunch', '--disable-x11-autolaunch', d)}"
>>
>> Ross
>>
> I've looked into the configure script and found that autolaunch 
> feature is depending on x11, in other words using --with-x/--without-x 
> implies --enable-x11-autolaunch/--disable-x11-autolaunch, so I guess 
> the initial EXTRA_OECONF_X line will do pretty much the same thing.
>
> EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', 
> '--with-x', '--without-x', d)}"
>
and the same applies for EXTRA_OECONF_X_virtclass-native disabling X 
will disable autolaunch feature, so I'll keep the initial line as well.

Radu
Ross Burton July 27, 2012, 10:02 a.m.
On 27 July 2012 07:10, Radu Moisan <radu.moisan@intel.com> wrote:
> I've looked into the configure script and found that autolaunch feature is
> depending on x11, in other words using --with-x/--without-x implies
> --enable-x11-autolaunch/--disable-x11-autolaunch, so I guess the initial
> EXTRA_OECONF_X line will do pretty much the same thing.

Using --enable-x11-autolaunch (and --disable) make it obvious what the
intention is, and is the option exposed by DBus.  --with-x is an
artifact of using AC_PATH_XTRA, so if dbus decided to use pkg-config
to find the X headers --with-x will disappear.

Ross