dbus-native --with-x

dbus-native --with-x

[Phil Blundell]

Is there any compelling reason why dbus-native needs to be built
--with-x?  This seems to be causing quite a large stack of native X11
packages to get built with, as far as I can tell, no useful result.

dbus-native itself is pulled in by way of insane.bbclass ->
desktop-file-utils-native -> glib-2.0-native, which I guess is
reasonable.  Though, as a future project, it might be nice to try to
curtail the dependency on d-f-u-native if there aren't actually
any .desktop files being shipped.

p.

Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 17:01 +0100, Phil Blundell wrote:
> Is there any compelling reason why dbus-native needs to be built
> --with-x?  This seems to be causing quite a large stack of native X11
> packages to get built with, as far as I can tell, no useful result.

Oh, on the subject of out-of-control dependency chains, my other pet
bugbear at the moment is rpm-native:

"rpm-native" -> "bzip2-native"
"rpm-native" -> "db-native"
"rpm-native" -> "perl-native"
"rpm-native" -> "openssl-native"
"rpm-native" -> "expat-native"
"rpm-native" -> "autoconf-native"
"rpm-native" -> "automake-native"
"rpm-native" -> "libtool-native"
"rpm-native" -> "gnu-config-native"
"rpm-native" -> "gettext-native"
"rpm-native" -> "python-native"
"rpm-native" -> "acl-native"
"rpm-native" -> "elfutils-native"
"rpm-native" -> "libpcre-native"
"rpm-native" -> "zlib-native"
"rpm-native" -> "popt-native"
"rpm-native" -> "attr-native"

As far as I can tell, the native rpm is never being used in any way
which requires it to have openssl, and I suspect the same is probably
true for some of the other libs above.  Does anybody happen to know what
features rpm-native actually requires for correct operation?

p.

Re: dbus-native --with-x

[Koen Kooi]

Op 1 jun 2011, om 18:03 heeft Phil Blundell het volgende geschreven:

> On Wed, 2011-06-01 at 17:01 +0100, Phil Blundell wrote:
>> Is there any compelling reason why dbus-native needs to be built
>> --with-x?  This seems to be causing quite a large stack of native X11
>> packages to get built with, as far as I can tell, no useful result.
> 
> Oh, on the subject of out-of-control dependency chains, my other pet
> bugbear at the moment is rpm-native:
> 
> "rpm-native" -> "bzip2-native"
> "rpm-native" -> "db-native"
> "rpm-native" -> "perl-native"
> "rpm-native" -> "openssl-native"
> "rpm-native" -> "expat-native"
> "rpm-native" -> "autoconf-native"
> "rpm-native" -> "automake-native"
> "rpm-native" -> "libtool-native"
> "rpm-native" -> "gnu-config-native"
> "rpm-native" -> "gettext-native"
> "rpm-native" -> "python-native"
> "rpm-native" -> "acl-native"
> "rpm-native" -> "elfutils-native"
> "rpm-native" -> "libpcre-native"
> "rpm-native" -> "zlib-native"
> "rpm-native" -> "popt-native"
> "rpm-native" -> "attr-native"
> 
> As far as I can tell, the native rpm is never being used in any way
> which requires it to have openssl, and I suspect the same is probably
> true for some of the other libs above.  Does anybody happen to know what
> features rpm-native actually requires for correct operation?

Furthermore, rpm-native seems to get built even if you don't select rpm as package format!

regards,

Koen

Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 18:11 +0200, Koen Kooi wrote:
> Furthermore, rpm-native seems to get built even if you don't select rpm as package format!

Yeah, it's called in by package.bbclass:

# rpm is used for the per-file dependency identification
PACKAGE_DEPENDS += "rpm-native"

As far as I can tell, the only part that actually gets used is rpmdeps
and it does seem like there ought to be a more lightweight way of
obtaining that one binary than building a full rpm and all its
dependencies.

p.

Re: dbus-native --with-x

[Mark Hatle]

On 6/1/11 11:16 AM, Phil Blundell wrote:
> On Wed, 2011-06-01 at 18:11 +0200, Koen Kooi wrote:
>> Furthermore, rpm-native seems to get built even if you don't select rpm as package format!
> 
> Yeah, it's called in by package.bbclass:
> 
> # rpm is used for the per-file dependency identification
> PACKAGE_DEPENDS += "rpm-native"
> 
> As far as I can tell, the only part that actually gets used is rpmdeps
> and it does seem like there ought to be a more lightweight way of
> obtaining that one binary than building a full rpm and all its
> dependencies.

As you mentioned rpm-native is being used for two reasons.  1 if rpm target
package are selected, it's being used to build, manage and install (rootfs) the
packages.

The other place, where it's always used, is the rpmdeps calculations.

> "rpm-native" -> "bzip2-native"

Above is used as RPM needs bzip2 to compress components that end up in packages.

> "rpm-native" -> "db-native"

Back-end DB is well, Berkley DB.

> "rpm-native" -> "perl-native"

Perl could be disabled if we don't need the perl interfaces to RPM.

> "rpm-native" -> "openssl-native"

OpenSSL is used for signing if I remember correctly.

> "rpm-native" -> "expat-native"

expat is needed for some XML parsing.  (Currently only internally to RPM, but
eventually it's thought this will be used for other purposes.)

> "rpm-native" -> "autoconf-native"
> "rpm-native" -> "automake-native"
> "rpm-native" -> "libtool-native"
> "rpm-native" -> "gnu-config-native"
> "rpm-native" -> "gettext-native"

Above are needed because of configure...

> "rpm-native" -> "python-native"

If we disable python interfaces to RPM, then this can be disabled.

> "rpm-native" -> "acl-native"

ACL's are needed for some filesystem access on rootfs generation.

> "rpm-native" -> "elfutils-native"

elfutils is used for rpmdeps, among other things.

> "rpm-native" -> "libpcre-native"

this is needed for package installation and creation... it's the pattern
recognition.

> "rpm-native" -> "zlib-native"

zlib is needed, similarly to bzip2, in order to compress/extract specific items
that may end up in a package.

> "rpm-native" -> "popt-native"

popt is the command line argument processing used globally within RPM and it's
sub commands.

> "rpm-native" -> "attr-native"

attr is needed similar to the acl stuff, when constructing rootfs components.

--

So in the above, perl and python are really the only items that could be disabled.

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 11:48 -0500, Mark Hatle wrote:
> So in the above, perl and python are really the only items that could be disabled.

Just to be clear, in the list you mentioned, were you talking about the
usage of rpm-native for rpmdeps, or the usage by package_rpm.bbclass
itself?

If we can avoid building perl-native and python-native then that
certainly sounds like a win on its own, though :-)

p.

Re: dbus-native --with-x

[Mark Hatle]

On 6/1/11 11:54 AM, Phil Blundell wrote:
> On Wed, 2011-06-01 at 11:48 -0500, Mark Hatle wrote:
>> So in the above, perl and python are really the only items that could be disabled.
> 
> Just to be clear, in the list you mentioned, were you talking about the
> usage of rpm-native for rpmdeps, or the usage by package_rpm.bbclass
> itself?

I was talking about rpm-native recipe in general, and how it's used.

rpmdeps requires a good chunk of the rpm infrastructure (even if we don't end up
using rpmbuild or rpm commands during the build..)

> If we can avoid building perl-native and python-native then that
> certainly sounds like a win on its own, though :-)

It "should" be as simple and adding --without-perl and --without-python to the
configuration line...  but I haven't tried it.

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
> On 6/1/11 11:54 AM, Phil Blundell wrote:
> > On Wed, 2011-06-01 at 11:48 -0500, Mark Hatle wrote:
> >> So in the above, perl and python are really the only items that could be disabled.
> > 
> > Just to be clear, in the list you mentioned, were you talking about the
> > usage of rpm-native for rpmdeps, or the usage by package_rpm.bbclass
> > itself?
> 
> I was talking about rpm-native recipe in general, and how it's used.
> 
> rpmdeps requires a good chunk of the rpm infrastructure (even if we don't end up
> using rpmbuild or rpm commands during the build..)

Do you happen to have a list of what exactly rpmdeps does require?
Based on the descriptions you gave before, I'm guessing that it probably
doesn't need openssl (since, afaik, it doesn't do any signing) or pcre
(since it isn't building any packages) or acl, attr, bzip and zlib
(since it also isn't installing anything).  

It presumably does still need pcre, and I have no idea whether it needs
db or expat.

> It "should" be as simple and adding --without-perl and --without-python to the
> configuration line...  but I haven't tried it.

Righto.  I'll give that a try later and see what happens.

p.

rpmdeps, was Re: dbus-native --with-x

[Mark Hatle]

On 6/1/11 12:08 PM, Phil Blundell wrote:
> On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
>> On 6/1/11 11:54 AM, Phil Blundell wrote:
>>> On Wed, 2011-06-01 at 11:48 -0500, Mark Hatle wrote:
>>>> So in the above, perl and python are really the only items that could be disabled.
>>>
>>> Just to be clear, in the list you mentioned, were you talking about the
>>> usage of rpm-native for rpmdeps, or the usage by package_rpm.bbclass
>>> itself?
>>
>> I was talking about rpm-native recipe in general, and how it's used.
>>
>> rpmdeps requires a good chunk of the rpm infrastructure (even if we don't end up
>> using rpmbuild or rpm commands during the build..)
> 
> Do you happen to have a list of what exactly rpmdeps does require?
> Based on the descriptions you gave before, I'm guessing that it probably
> doesn't need openssl (since, afaik, it doesn't do any signing) or pcre
> (since it isn't building any packages) or acl, attr, bzip and zlib
> (since it also isn't installing anything).  

rpmdeps uses, according to ldd:

        linux-vdso.so.1
        librpm-5.4.so
        librpmdb-5.4.so
        librpmio-5.4.so
        librpmmisc-5.4.so
        libm.so.6
        libdl.so.2
        libacl.so.1
        libattr.so.1
        libpcreposix.so.0
        libdb-5.1.so
        libmagic.so.1
        liblzma.so.5
        libbz2.so.0
        libz.so.1
        libpthread.so.0
        librt.so.1
        libelf.so.1
        libpopt.so.0
        libssl.so.0.9.8
        libcrypto.so.0.9.8
        libpcre.so.0
        libc.so.6
        libgcc_s.so.1
        /lib64/ld-linux-x86-64.so.2 (0x0000003c51800000)

The issue is that it uses the librpm, librpmdb, librpmio, and librpmmisc
libraries.  These libraries provide and use all of the rest of the components.

> It presumably does still need pcre, and I have no idea whether it needs
> db or expat.

pcre is used to handle the file lists and any patterns to generate the lists, or
dependent informtion.  So that is needed.  expat may be needed in the future, I
don't see that it is today.

>> It "should" be as simple and adding --without-perl and --without-python to the
>> configuration line...  but I haven't tried it.
> 
> Righto.  I'll give that a try later and see what happens.
> 
> p.
> 
> 

Re: rpmdeps, was Re: dbus-native --with-x

[Koen Kooi]

Op 1 jun 2011, om 20:55 heeft Mark Hatle het volgende geschreven:

> On 6/1/11 12:08 PM, Phil Blundell wrote:
>> On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
>>> On 6/1/11 11:54 AM, Phil Blundell wrote:
>>>> On Wed, 2011-06-01 at 11:48 -0500, Mark Hatle wrote:
>>>>> So in the above, perl and python are really the only items that could be disabled.
>>>> 
>>>> Just to be clear, in the list you mentioned, were you talking about the
>>>> usage of rpm-native for rpmdeps, or the usage by package_rpm.bbclass
>>>> itself?
>>> 
>>> I was talking about rpm-native recipe in general, and how it's used.
>>> 
>>> rpmdeps requires a good chunk of the rpm infrastructure (even if we don't end up
>>> using rpmbuild or rpm commands during the build..)
>> 
>> Do you happen to have a list of what exactly rpmdeps does require?
>> Based on the descriptions you gave before, I'm guessing that it probably
>> doesn't need openssl (since, afaik, it doesn't do any signing) or pcre
>> (since it isn't building any packages) or acl, attr, bzip and zlib
>> (since it also isn't installing anything).  
> 
> rpmdeps uses, according to ldd:
> 
>        linux-vdso.so.1
>        librpm-5.4.so
>        librpmdb-5.4.so
>        librpmio-5.4.so
>        librpmmisc-5.4.so
>        libm.so.6
>        libdl.so.2
>        libacl.so.1
>        libattr.so.1
>        libpcreposix.so.0
>        libdb-5.1.so
>        libmagic.so.1
>        liblzma.so.5
>        libbz2.so.0
>        libz.so.1
>        libpthread.so.0
>        librt.so.1
>        libelf.so.1
>        libpopt.so.0
>        libssl.so.0.9.8
>        libcrypto.so.0.9.8
>        libpcre.so.0
>        libc.so.6
>        libgcc_s.so.1
>        /lib64/ld-linux-x86-64.so.2 (0x0000003c51800000)
> 
> The issue is that it uses the librpm, librpmdb, librpmio, and librpmmisc
> libraries.  These libraries provide and use all of the rest of the components.


What is rpmdeps actually used for in package.bbclass when you're not using rpm as package format?

regards,

Koen

Re: rpmdeps, was Re: dbus-native --with-x

[Mark Hatle]

On 6/1/11 2:00 PM, Koen Kooi wrote:
> 
> Op 1 jun 2011, om 20:55 heeft Mark Hatle het volgende geschreven:
> 
>> On 6/1/11 12:08 PM, Phil Blundell wrote:
>>> On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
>>>> On 6/1/11 11:54 AM, Phil Blundell wrote:
>>>>> On Wed, 2011-06-01 at 11:48 -0500, Mark Hatle wrote:
>>>>>> So in the above, perl and python are really the only items that could be disabled.
>>>>>
>>>>> Just to be clear, in the list you mentioned, were you talking about the
>>>>> usage of rpm-native for rpmdeps, or the usage by package_rpm.bbclass
>>>>> itself?
>>>>
>>>> I was talking about rpm-native recipe in general, and how it's used.
>>>>
>>>> rpmdeps requires a good chunk of the rpm infrastructure (even if we don't end up
>>>> using rpmbuild or rpm commands during the build..)
>>>
>>> Do you happen to have a list of what exactly rpmdeps does require?
>>> Based on the descriptions you gave before, I'm guessing that it probably
>>> doesn't need openssl (since, afaik, it doesn't do any signing) or pcre
>>> (since it isn't building any packages) or acl, attr, bzip and zlib
>>> (since it also isn't installing anything).  
>>
>> rpmdeps uses, according to ldd:
>>
>>        linux-vdso.so.1
>>        librpm-5.4.so
>>        librpmdb-5.4.so
>>        librpmio-5.4.so
>>        librpmmisc-5.4.so
>>        libm.so.6
>>        libdl.so.2
>>        libacl.so.1
>>        libattr.so.1
>>        libpcreposix.so.0
>>        libdb-5.1.so
>>        libmagic.so.1
>>        liblzma.so.5
>>        libbz2.so.0
>>        libz.so.1
>>        libpthread.so.0
>>        librt.so.1
>>        libelf.so.1
>>        libpopt.so.0
>>        libssl.so.0.9.8
>>        libcrypto.so.0.9.8
>>        libpcre.so.0
>>        libc.so.6
>>        libgcc_s.so.1
>>        /lib64/ld-linux-x86-64.so.2 (0x0000003c51800000)
>>
>> The issue is that it uses the librpm, librpmdb, librpmio, and librpmmisc
>> libraries.  These libraries provide and use all of the rest of the components.
> 
> 
> What is rpmdeps actually used for in package.bbclass when you're not using rpm as package format?

In package.bbclass:

package_do_filedeps is where rpmdeps is used.

This captures file dependencies on a per-file basis.  The dependencies captured
include interpreter information as well as ELF sonames and related.

There are/were a number of small dependencies that were being missed in the
past, this is a complete set of dependencies which are captured (again on a
per-file basis).

The reason we capture on a per-file is so that additional tooling can be
developed to allow people to view, understand and modify the rootfs images they
are working on.  One of the things people like to do is understand why perl or
python is being included on a small filesystem... the per-file dependencies can
be used to "see" this, and also allow people to skip specific files and thus
affect the dependencies within their system.  (Note, this tool does not yet
exist!  But I expect that it will at some point.)

(There are three places you can typically affect the dependencies of the end
device.  During recipe creation (i.e. manual RDEPENDS), during source
configuration, and during binary package creation...  this gives us the ability
to hook in and modify the package creation -- or re-create the packages based on
new criteria.)

(BTW besides the rpmdeps, rpm components are also used in the
split_and_strip_files function...  but this is really just debugedit)


--Mark

> regards,
> 
> Koen
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: rpmdeps, was Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 13:55 -0500, Mark Hatle wrote:
> The issue is that it uses the librpm, librpmdb, librpmio, and librpmmisc
> libraries.  These libraries provide and use all of the rest of the components.

Right, but would rpmdeps still be able to do what it needs to if rpm was
built --without-openssl etc?  The output from ldd isn't especially
enlightening in itself because all that tells us is which libraries
librpm was built against.

p.

Re: rpmdeps, was Re: dbus-native --with-x

[Mark Hatle]

On 6/1/11 3:02 PM, Phil Blundell wrote:
> On Wed, 2011-06-01 at 13:55 -0500, Mark Hatle wrote:
>> The issue is that it uses the librpm, librpmdb, librpmio, and librpmmisc
>> libraries.  These libraries provide and use all of the rest of the components.
> 
> Right, but would rpmdeps still be able to do what it needs to if rpm was
> built --without-openssl etc?  The output from ldd isn't especially
> enlightening in itself because all that tells us is which libraries
> librpm was built against.
> 
> p.
> 
> 

I'm not sure if the libraries that RPM uses would even be able to link w/o
openssl.  (I never tried it.)  But that will affect people who are using RPM
packages as signing and validation routines come from openssl.

--Mark

Re: rpmdeps, was Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 16:17 -0500, Mark Hatle wrote:
> I'm not sure if the libraries that RPM uses would even be able to link w/o
> openssl.  (I never tried it.)  But that will affect people who are using RPM
> packages as signing and validation routines come from openssl.

Sure, but if rpmdeps doesn't need those bits then we could have two
recipes: a heavy one for those people who want rpm packages, and a
lighter one for those who need rpmdeps to make package.bbclass work but
don't otherwise have any requirement for rpm.

p.

Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
> It "should" be as simple and adding --without-perl and --without-python to the
> configuration line...  but I haven't tried it.

Turns out that rpm-native already does this, but (like the dbus case)
there is no matching logic to get the DEPENDS right.

Another instance of a similar thing appears to be sqlite3-native, which
DEPENDS on tcl-native even though it's configured --without-tcl.

p.

Re: dbus-native --with-x

[Tom Rini]

On 06/01/2011 01:22 PM, Phil Blundell wrote:
> On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
>> It "should" be as simple and adding --without-perl and --without-python to the
>> configuration line...  but I haven't tried it.
> 
> Turns out that rpm-native already does this, but (like the dbus case)
> there is no matching logic to get the DEPENDS right.
> 
> Another instance of a similar thing appears to be sqlite3-native, which
> DEPENDS on tcl-native even though it's configured --without-tcl.

Since this keeps coming up, maybe it needs a comment.  sqlite3 needs
tcl-native (tclsh) to generate a header file.  No tclsh, no sqlite3.

-- 
Tom Rini
Mentor Graphics Corporation

Re: dbus-native --with-x

[Henning Heinold]

On Wed, Jun 01, 2011 at 03:00:37PM -0700, Tom Rini wrote:
> On 06/01/2011 01:22 PM, Phil Blundell wrote:
> > On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
> >> It "should" be as simple and adding --without-perl and --without-python to the
> >> configuration line...  but I haven't tried it.
> > 
> > Turns out that rpm-native already does this, but (like the dbus case)
> > there is no matching logic to get the DEPENDS right.
> > 
> > Another instance of a similar thing appears to be sqlite3-native, which
> > DEPENDS on tcl-native even though it's configured --without-tcl.
> 
> Since this keeps coming up, maybe it needs a comment.  sqlite3 needs
> tcl-native (tclsh) to generate a header file.  No tclsh, no sqlite3.

I thought that is diffrent with 3.7.x version of sqlite3.

Bye Henning

Re: dbus-native --with-x

[Tom Rini]

On 06/01/2011 03:07 PM, Henning Heinold wrote:
> On Wed, Jun 01, 2011 at 03:00:37PM -0700, Tom Rini wrote:
>> On 06/01/2011 01:22 PM, Phil Blundell wrote:
>>> On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
>>>> It "should" be as simple and adding --without-perl and --without-python to the
>>>> configuration line...  but I haven't tried it.
>>>
>>> Turns out that rpm-native already does this, but (like the dbus case)
>>> there is no matching logic to get the DEPENDS right.
>>>
>>> Another instance of a similar thing appears to be sqlite3-native, which
>>> DEPENDS on tcl-native even though it's configured --without-tcl.
>>
>> Since this keeps coming up, maybe it needs a comment.  sqlite3 needs
>> tcl-native (tclsh) to generate a header file.  No tclsh, no sqlite3.
> 
> I thought that is diffrent with 3.7.x version of sqlite3.

Nope.  That's what I checked this against.  In oe.dev
a2c3af2d608b1b713018d688b00e03873a538993 is where we set all of this right.

-- 
Tom Rini
Mentor Graphics Corporation

Re: dbus-native --with-x

[Mark Hatle]

On 6/1/11 5:22 PM, Tom Rini wrote:
> On 06/01/2011 03:07 PM, Henning Heinold wrote:
>> On Wed, Jun 01, 2011 at 03:00:37PM -0700, Tom Rini wrote:
>>> On 06/01/2011 01:22 PM, Phil Blundell wrote:
>>>> On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
>>>>> It "should" be as simple and adding --without-perl and --without-python to the
>>>>> configuration line...  but I haven't tried it.
>>>>
>>>> Turns out that rpm-native already does this, but (like the dbus case)
>>>> there is no matching logic to get the DEPENDS right.
>>>>
>>>> Another instance of a similar thing appears to be sqlite3-native, which
>>>> DEPENDS on tcl-native even though it's configured --without-tcl.
>>>
>>> Since this keeps coming up, maybe it needs a comment.  sqlite3 needs
>>> tcl-native (tclsh) to generate a header file.  No tclsh, no sqlite3.
>>
>> I thought that is diffrent with 3.7.x version of sqlite3.
> 
> Nope.  That's what I checked this against.  In oe.dev
> a2c3af2d608b1b713018d688b00e03873a538993 is where we set all of this right.
> 

Someone needs to go in and document the recipe.  It's clear there is confusion
and a quick comment in the recipe can likely stop future discussion.

--Mark

Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 15:22 -0700, Tom Rini wrote:
> On 06/01/2011 03:07 PM, Henning Heinold wrote:
> > On Wed, Jun 01, 2011 at 03:00:37PM -0700, Tom Rini wrote:
> >> On 06/01/2011 01:22 PM, Phil Blundell wrote:
> >>> On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
> >>>> It "should" be as simple and adding --without-perl and --without-python to the
> >>>> configuration line...  but I haven't tried it.
> >>>
> >>> Turns out that rpm-native already does this, but (like the dbus case)
> >>> there is no matching logic to get the DEPENDS right.
> >>>
> >>> Another instance of a similar thing appears to be sqlite3-native, which
> >>> DEPENDS on tcl-native even though it's configured --without-tcl.
> >>
> >> Since this keeps coming up, maybe it needs a comment.  sqlite3 needs
> >> tcl-native (tclsh) to generate a header file.  No tclsh, no sqlite3.
> > 
> > I thought that is diffrent with 3.7.x version of sqlite3.
> 
> Nope.  That's what I checked this against.  In oe.dev
> a2c3af2d608b1b713018d688b00e03873a538993 is where we set all of this right.

Actually, it looks to me like Henning is right.  In 3.7.6.2, which seems
to be what we have in oe-core right now, I can't find any trace of the
old tcl script that was being used for header generation.  Which file(s)
did you find the tcl requirement in?

p.

Re: dbus-native --with-x

[Tom Rini]

On 06/02/2011 02:08 AM, Phil Blundell wrote:
> On Wed, 2011-06-01 at 15:22 -0700, Tom Rini wrote:
>> On 06/01/2011 03:07 PM, Henning Heinold wrote:
>>> On Wed, Jun 01, 2011 at 03:00:37PM -0700, Tom Rini wrote:
>>>> On 06/01/2011 01:22 PM, Phil Blundell wrote:
>>>>> On Wed, 2011-06-01 at 11:58 -0500, Mark Hatle wrote:
>>>>>> It "should" be as simple and adding --without-perl and --without-python to the
>>>>>> configuration line...  but I haven't tried it.
>>>>>
>>>>> Turns out that rpm-native already does this, but (like the dbus case)
>>>>> there is no matching logic to get the DEPENDS right.
>>>>>
>>>>> Another instance of a similar thing appears to be sqlite3-native, which
>>>>> DEPENDS on tcl-native even though it's configured --without-tcl.
>>>>
>>>> Since this keeps coming up, maybe it needs a comment.  sqlite3 needs
>>>> tcl-native (tclsh) to generate a header file.  No tclsh, no sqlite3.
>>>
>>> I thought that is diffrent with 3.7.x version of sqlite3.
>>
>> Nope.  That's what I checked this against.  In oe.dev
>> a2c3af2d608b1b713018d688b00e03873a538993 is where we set all of this right.
> 
> Actually, it looks to me like Henning is right.  In 3.7.6.2, which seems
> to be what we have in oe-core right now, I can't find any trace of the
> old tcl script that was being used for header generation.  Which file(s)
> did you find the tcl requirement in?

I guess I've just gone crazy (or crazier if you prefer) and I can't find
it anymore in 3.7.x.

-- 
Tom Rini
Mentor Graphics Corporation

Re: dbus-native --with-x

[Phil Blundell]

On Thu, 2011-06-02 at 10:04 -0700, Tom Rini wrote:
> I guess I've just gone crazy (or crazier if you prefer) and I can't find
> it anymore in 3.7.x.

Okay.  So do we think the tcl dependency can be dropped?

p.

Re: dbus-native --with-x

[Tom Rini]

On 06/02/2011 12:21 PM, Phil Blundell wrote:
> On Thu, 2011-06-02 at 10:04 -0700, Tom Rini wrote:
>> I guess I've just gone crazy (or crazier if you prefer) and I can't find
>> it anymore in 3.7.x.
> 
> Okay.  So do we think the tcl dependency can be dropped?

Yes.

-- 
Tom Rini
Mentor Graphics Corporation

Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 15:00 -0700, Tom Rini wrote:
> Since this keeps coming up, maybe it needs a comment.  sqlite3 needs
> tcl-native (tclsh) to generate a header file.  No tclsh, no sqlite3.

Oh yeah, right.

Maybe we should just patch sqlite to generate the header using something
else.  There's no real heavy lifting going on in that script and it
could easily be done in python for example.

If sqlite is a requirement for pseudo, and hence an unavoidable dep for
every build, it seems worth going to a bit of effort to avoid building
stuff like tcl if that's avoidable.

p.

Re: dbus-native --with-x

[Koen Kooi]

Op 1 jun 2011, om 18:01 heeft Phil Blundell het volgende geschreven:

> Is there any compelling reason why dbus-native needs to be built
> --with-x?  This seems to be causing quite a large stack of native X11
> packages to get built with, as far as I can tell, no useful result.

I agree, for -native --with-x is overkill

regards,

Koen

Re: dbus-native --with-x

[Phil Blundell]

On Wed, 2011-06-01 at 18:10 +0200, Koen Kooi wrote:
> Op 1 jun 2011, om 18:01 heeft Phil Blundell het volgende geschreven:
> 
> > Is there any compelling reason why dbus-native needs to be built
> > --with-x?  This seems to be causing quite a large stack of native X11
> > packages to get built with, as far as I can tell, no useful result.
> 
> I agree, for -native --with-x is overkill

Actually, it turns out that dbus.inc already has:

EXTRA_OECONF_X = "--with-x"
EXTRA_OECONF_X_virtclass-native = "--without-x"

... it's just that it doesn't have any similar code to squash the
dependency on virtual/libx11 in the native case, so you end up building
the x libs anyway.  Doh.

Knocking that dependency out has reduced the task count for
micro-base-image from 938 to 748, which seems like a worthwhile saving.
I'll send a patch later once I've verified that the image build does
actually succeed with that change.

p.