connman dependency of readline

connman dependency of readline

[claus.stovgaard]

Hi

I am starting to use Yocto / OpenEmbedded, where I was looking into
using ConnMan as network manager.

Though I was wondering about the readline dependency.
Looking at the recipe 
https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-connectivity/connman/connman.inc
it is set to always depend on readline in the DEPENDS variable, even
though as far as I know it is only the connmanctl which depend on
readline.
In EXTRA_OECONF the --enable-client is hardcoded.

The client is though not included in the image unless you also add
connman-client.

So I am thinking on creating a patch where I create a
PACKAGECONFIG[readline] like bluez5, as I would not need the client and
will need not to include readline because of GPLv3.

I guess email is the prefered way for patches compared to github pull
requests?

Instead of my idea of creating as PACKAGECONFIG[readline], is there a
better way so it is only included if connman-client is used, instead of
just connman?

Have a nice weekend.
Claus Stovgaard

Re: connman dependency of readline

[Khem Raj]

On Sat, Dec 7, 2019 at 7:40 AM <claus.stovgaard@gmail.com> wrote:
>
> Hi
>
> I am starting to use Yocto / OpenEmbedded, where I was looking into
> using ConnMan as network manager.
>
> Though I was wondering about the readline dependency.
> Looking at the recipe
> https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-connectivity/connman/connman.inc
> it is set to always depend on readline in the DEPENDS variable, even
> though as far as I know it is only the connmanctl which depend on
> readline.
> In EXTRA_OECONF the --enable-client is hardcoded.
>
> The client is though not included in the image unless you also add
> connman-client.
>
> So I am thinking on creating a patch where I create a
> PACKAGECONFIG[readline] like bluez5, as I would not need the client and
> will need not to include readline because of GPLv3.
>
> I guess email is the prefered way for patches compared to github pull
> requests?

yes

>
> Instead of my idea of creating as PACKAGECONFIG[readline], is there a
> better way so it is only included if connman-client is used, instead of
> just connman?

you are on the right track

>
> Have a nice weekend.
> Claus Stovgaard
>
>
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: connman dependency of readline

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org <openembedded-core-
> bounces@lists.openembedded.org> On Behalf Of claus.stovgaard@gmail.com
> Sent: den 7 december 2019 16:41
> To: oe-core <openembedded-core@lists.openembedded.org>
> Subject: [OE-core] connman dependency of readline
> 
> Hi
> 
> I am starting to use Yocto / OpenEmbedded, where I was looking into
> using ConnMan as network manager.
> 
> Though I was wondering about the readline dependency.
> Looking at the recipe
> https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-connectivity/connman/connman.inc
> it is set to always depend on readline in the DEPENDS variable, even
> though as far as I know it is only the connmanctl which depend on
> readline.
> In EXTRA_OECONF the --enable-client is hardcoded.
> 
> The client is though not included in the image unless you also add
> connman-client.
> 
> So I am thinking on creating a patch where I create a
> PACKAGECONFIG[readline] like bluez5, as I would not need the client and
> will need not to include readline because of GPLv3.

If readline is only needed to build the connman client and it is 
packaged in a separate package, then you are only affected by 
readline's GPL-3.0 license if you install that package. If you do 
not install it you are ok even if readline is needed during the 
build. So there should not be any real need to disable the building 
of the client.

> I guess email is the prefered way for patches compared to github pull
> requests?
> 
> Instead of my idea of creating as PACKAGECONFIG[readline], is there a
> better way so it is only included if connman-client is used, instead of
> just connman?
> 
> Have a nice weekend.
> Claus Stovgaard

//Peter

Re: connman dependency of readline

[claus.stovgaard]

> > it is set to always depend on readline in the DEPENDS variable,
> > even
> > though as far as I know it is only the connmanctl which depend on
> > readline.
> > In EXTRA_OECONF the --enable-client is hardcoded.
> > 
> > The client is though not included in the image unless you also add
> > connman-client.
> > 
> > So I am thinking on creating a patch where I create a
> > PACKAGECONFIG[readline] like bluez5, as I would not need the client
> > and
> > will need not to include readline because of GPLv3.
> 
> If readline is only needed to build the connman client and it is 
> packaged in a separate package, then you are only affected by 
> readline's GPL-3.0 license if you install that package. If you do 
> not install it you are ok even if readline is needed during the 
> build. So there should not be any real need to disable the building 
> of the client.

Thanks for your reply. Was also mixing DEPENDS up with RDEPENDS inside
my head.

Before your mail I had created a small patch and sent. I was
considering just to request it beeing dropped, but on the otherhand it
make it possible to use 

INCOMPATIBLE_LICENSE = "GPL-3.0"

without getting below error. 

ERROR: Nothing PROVIDES 'readline' (but /openembedded/oe-
core/meta/recipes-connectivity/connman/connman_1.37.bb DEPENDS on or
otherwise requires it)
readline was skipped: it has an incompatible license: GPLv3+

Though fine with me if the patch is dropped.

As a side note, is there a way for specifing INCOMPATIBLE_LICENSE on an
image level, and not as here on the build level? If this is the case,
there is no need for my change at all.

Regards
Claus

Re: connman dependency of readline

[Peter Kjellerstedt]

> -----Original Message-----
> From: claus.stovgaard@gmail.com <claus.stovgaard@gmail.com>
> Sent: den 11 december 2019 22:11
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; oe-core
> <openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] connman dependency of readline
> 
> > > it is set to always depend on readline in the DEPENDS variable,
> > > even though as far as I know it is only the connmanctl which 
> > > depend on readline. In EXTRA_OECONF the --enable-client is 
> > > hardcoded.
> > >
> > > The client is though not included in the image unless you also 
> > > add connman-client.
> > >
> > > So I am thinking on creating a patch where I create a
> > > PACKAGECONFIG[readline] like bluez5, as I would not need the 
> > > client and will need not to include readline because of GPLv3.
> >
> > If readline is only needed to build the connman client and it is
> > packaged in a separate package, then you are only affected by
> > readline's GPL-3.0 license if you install that package. If you do
> > not install it you are ok even if readline is needed during the
> > build. So there should not be any real need to disable the
> > building of the client.
> 
> Thanks for your reply. Was also mixing DEPENDS up with RDEPENDS 
> inside my head.
> 
> Before your mail I had created a small patch and sent. I was
> considering just to request it being dropped, but on the 
> other hand it makes it possible to use
> 
> INCOMPATIBLE_LICENSE = "GPL-3.0"
> 
> without getting below error.
> 
> ERROR: Nothing PROVIDES 'readline' (but /openembedded/oe-
> core/meta/recipes-connectivity/connman/connman_1.37.bb DEPENDS on 
> or otherwise requires it)
> readline was skipped: it has an incompatible license: GPLv3+
> 
> Though fine with me if the patch is dropped.
> 
> As a side note, is there a way for specifing INCOMPATIBLE_LICENSE 
> on an image level, and not as here on the build level? If this is 
> the case, there is no need for my change at all.

Yes. About two months ago, Alexander Kanavin added support for setting 
INCOMPATIBLE_LICENSE per image (see commit fd50395b in OE-Core):

INCOMPATIBLE_LICENSE_pn-core-image-minimal = "GPL-3.0 LGPL-3.0"

> Regards
> Claus

//Peter