[PATCH] libpcap: weaken bluez-libs dependency

[PATCH] libpcap: weaken bluez-libs dependency

[Roman I Khimov]

libpcap can be used in distros where no bluetooth support will ever
exist. So this dependency should be weakened to only exist in distros
that explicitly need bluetooth.
---
 recipes/libpcap/libpcap.inc |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/recipes/libpcap/libpcap.inc b/recipes/libpcap/libpcap.inc
index 4468a4b..81bf826 100644
--- a/recipes/libpcap/libpcap.inc
+++ b/recipes/libpcap/libpcap.inc
@@ -2,7 +2,11 @@ DESCRIPTION = "Network Packet Capture Library"
 HOMEPAGE = "http://www.tcpdump.org/"
 SECTION = "libs/network"
 LICENSE = "BSD"
-DEPENDS = "bluez-libs flex-native bison-native"
+DEPENDS = " \
+	${@base_contains("COMBINED_FEATURES", "bluetooth", "bluez-libs", "", d)} \
+	flex-native \
+	bison-native \
+	"
 
 PR = "r1"
 
-- 
1.6.2.1


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [PATCH] libpcap: weaken bluez-libs dependency

[Koen Kooi]

On 15-04-09 10:36, Roman I Khimov wrote:
> libpcap can be used in distros where no bluetooth support will ever
> exist. So this dependency should be weakened to only exist in distros
> that explicitly need bluetooth.

NACK, no USE flags in OE. If you want a pcap without bluez you can 
either do:

libpcap.bb + libpcap-bluetooth.bb OR libpcap.bb + libpcap-no-bluetooth.bb

And add the needed virtuals.

Oh, and with 'distros' you mean 'images'.

regards,

Koen

Re: [PATCH] libpcap: weaken bluez-libs dependency

[Graeme Gregory]

On 04/15/2009 09:36 AM, Roman I Khimov wrote:
> libpcap can be used in distros where no bluetooth support will ever
> exist. So this dependency should be weakened to only exist in distros
> that explicitly need bluetooth.
> ---
>   recipes/libpcap/libpcap.inc |    6 +++++-
>   1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/recipes/libpcap/libpcap.inc b/recipes/libpcap/libpcap.inc
> index 4468a4b..81bf826 100644
> --- a/recipes/libpcap/libpcap.inc
> +++ b/recipes/libpcap/libpcap.inc
> @@ -2,7 +2,11 @@ DESCRIPTION = "Network Packet Capture Library"
>   HOMEPAGE = "http://www.tcpdump.org/"
>   SECTION = "libs/network"
>   LICENSE = "BSD"
> -DEPENDS = "bluez-libs flex-native bison-native"
> +DEPENDS = " \
> +	${@base_contains("COMBINED_FEATURES", "bluetooth", "bluez-libs", "", d)} \
> +	flex-native \
> +	bison-native \
> +	"
>
>   PR = "r1"
>
>    
NACK, this doesnt do what you think it does as you don't disable 
bluetooth via any form of alteration to the build system. You have 
created randomness in your build now.

Graeme

Re: [PATCH] libpcap: weaken bluez-libs dependency

[Roman I Khimov]

On Wednesday 15 April 2009 13:24:23 Graeme Gregory wrote:
> On 04/15/2009 09:36 AM, Roman I Khimov wrote:
> > +	${@base_contains("COMBINED_FEATURES", "bluetooth", "bluez-libs", "",
>
> NACK, this doesnt do what you think it does as you don't disable
> bluetooth via any form of alteration to the build system. 

It did exactly what I needed from it - kicked bluez-libs out of my build. With 
bluetooth-enabled distros it didn't change anything. Therefore I don't think 
it is true that

> You have created randomness in your build now.

Albeit you must be pointing to the fact that if I had bluez-libs already built 
that might change the behaviour which is true and can be fixed by 
ac_cv_header_bluetooth_bluetooth_h override in 
do_configure_prepend_bluetooth.

Re: [PATCH] libpcap: weaken bluez-libs dependency

[Roman I Khimov]

On Wednesday 15 April 2009 13:04:15 Koen Kooi wrote:
> On 15-04-09 10:36, Roman I Khimov wrote:
> > libpcap can be used in distros where no bluetooth support will ever
> > exist. So this dependency should be weakened to only exist in distros
> > that explicitly need bluetooth.
>
> NACK, no USE flags in OE. 

Even if hostap-daemon and wpa-supplicant and tasks already use FEATURES in 
similar fashion, changing package-task behaviour?

> If you want a pcap without bluez you can 
> either do:
>
> libpcap.bb + libpcap-bluetooth.bb OR libpcap.bb + libpcap-no-bluetooth.bb
>
> And add the needed virtuals.

Is this a policy? I'm not sure it makes sense to add tons 
of 'package-this', 'package-that', 'package-yet-another-thing',
'package-this-that-but-not-yet-another-thing' for every case.

I've used this 'virtual' kind of approach with two another packages but there 
I'd extended functionality by applying patches, so another package with all 
virtual stuff makes more sense. But here what I'm doing is configuring the 
same source to fit my needs and 'bluetooth' thing already exist in FEATURES. 
So how to use it if not this way?

Though if it is a policy around here, so be it.

Re: [PATCH] libpcap: weaken bluez-libs dependency

[Andrea Adami]

>Is this a policy?
The point is the produced binary should not have different configure
options and/or different runtime behaviours...hence the need for a
finer granularity.

However, this has the side-effect of bloating the number of requested
packages for almost every task.

Regards

Andrea

Re: [PATCH] libpcap: weaken bluez-libs dependency

[Holger Schurig]

> NACK, no USE flags in OE.

I'm not sure if this was a mis-design that I made.

When I modeled *.bb and *.bbclass files and wrote parts of the 
initial bitbake, I thought that USE variables lead even more to 
a combinatorical explosion (think package tests!) than the 
overrides I added.

I thought that overrides are strictly necessary to adapt to 
invidual board settings. And I thought that USE= is just handy, 
not neccessary. I also never wrote something about USE= in the 
design documents we had in the old wiki at that time.

In the mean-time I also had thought from time to time that USE 
would be nicer. However, partially we have USE, althought it's 
usually only for defining WHAT comes into image, now HOW to 
compile something. Examples of Gentoo-USE-like variables are 
DISTRO_FEATURES or MACHINE_FEATURES.


However, if we now would add USE like gentoo, I'd like to saner 
syntax than embedded anonymous python scripts :-)

Also, from quite early on it was clear that usage of overrides 
will be recorded and will e.g. into the filenames of generated 
*.ipk files. We'll have to think about how to do that for USE 
flags ...  (if we ever use them). Or how to circumvent this, 
e.g. using MACHINE or DISTRO, depending on where the USE flag 
was defined. But hey, that's all halfbaked, not bitbaked :-)



All historic mention is "AFAIK", it was several years ago, and 
other people like Chris or Mickey and some more from the old 
OPIE community also helped brainstorming.

Re: [PATCH] libpcap: weaken bluez-libs dependency

[Koen Kooi]

On 15-04-09 12:47, Holger Schurig wrote:
>> NACK, no USE flags in OE.
>
> I'm not sure if this was a mis-design that I made.
>
> When I modeled *.bb and *.bbclass files and wrote parts of the
> initial bitbake, I thought that USE variables lead even more to
> a combinatorical explosion (think package tests!) than the
> overrides I added.

Any form of USE flags means that package QA becomes practically 
impossible. I know that lots of people don't care about (package) QA, 
but I do.

regards,

Koen