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

login
register
mail settings
Submitter Radu Moisan
Date July 26, 2012, 6:17 a.m.
Message ID <1343283462-25435-1-git-send-email-radu.moisan@intel.com>
Download mbox | patch
Permalink /patch/33103/
State New
Headers show

Comments

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(-)
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

Patch

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 \