[PULL]Fix adding GDBM_File module for perl

[PULL]Fix adding GDBM_File module for perl

[Lu Jingdong]

Note: <commit_id> parameter assumed as 'HEAD'

  meta/recipes-devtools/perl/perl-5.8.8/config.sh                                     |    8
  meta/recipes-devtools/perl/perl-5.8.8/perl-enable-gdbm.patch                        |   17 +
  meta/recipes-devtools/perl/perl_5.8.8.bb                                            |    2

  meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.12-zlib.patch                 |  169 ++++++++++
  meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-data_types.patch          |   32 +
  meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-help-index-segfault.patch |   23 +
  meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-mosdo-crash.patch         |   11
  meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-powerpc.patch             |   12
  meta/recipes-extended/texinfo/texinfo_4.13a.bb                                      |   57 +++
  9 files changed, 327 insertions(+), 4 deletions(-)

Jingdong Lu (2):
       texinfo: Add new package
       Fix adding GDBM_File module for LSB test.

Pull URL: 
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jingdonglu/distro

-- 
Lu Jingdong
China, WindRiver

Re: [PULL]Fix adding GDBM_File module for perl

[Saul Wold]

On 11/01/2010 10:22 AM, Lu Jingdong wrote:
> Note:<commit_id>  parameter assumed as 'HEAD'
>
>    meta/recipes-devtools/perl/perl-5.8.8/config.sh                                     |    8
>    meta/recipes-devtools/perl/perl-5.8.8/perl-enable-gdbm.patch                        |   17 +
>    meta/recipes-devtools/perl/perl_5.8.8.bb                                            |    2
>
This patch looks OK to me and I will pull it.
(Nitin, please take note of this config change for your work).

>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.12-zlib.patch                 |  169 ++++++++++
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-data_types.patch          |   32 +
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-help-index-segfault.patch |   23 +
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-mosdo-crash.patch         |   11
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-powerpc.patch             |   12
>    meta/recipes-extended/texinfo/texinfo_4.13a.bb                                      |   57 +++

I am just reviewing the textinfo patch at this point and first comment 
is that you need to comment the patches, there is no information about 
their origin and why they are needed.

As we are adding a new recipe, is this based on the existing 
OpenEmbedded recipe and if so, you need to credit OE.  I noticed in OE 
that they have a different set of depends and patches, so I wanted to 
verify this.

Minor nit: for SRC_URI, you could use ${PN} as follows:
    http://ftp.gnu.org/gnu/${PN}/${PN}-${PV}.tar.gz

Sau!




>    9 files changed, 327 insertions(+), 4 deletions(-)
>
> Jingdong Lu (2):
>         texinfo: Add new package
>         Fix adding GDBM_File module for LSB test.
>
> Pull URL:
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jingdonglu/distro
>

Re: [PULL]Fix adding GDBM_File module for perl

[Mark Hatle]

I've been doing some thinking about how various perl and related components 
should be implemented if they do potentially optional things.

My concern is that by adding gdbm to the build, that other components will 
change and potentially require more disk space.  We really need a way to 
optionally use gdbm, if available in these configurations.  I'm really not sure 
if there is currently a way to tell bitbake:

I really want gdbm, but if nothing else wants it.. I don't want it.  Then for 
LSB specific builds, we manually require gdbm as an LSB requirement (due to the 
gdbm perl module requirements.)

Richard, any suggestions on how to work with this?

--Mark

On 11/1/10 5:22 AM, Lu Jingdong wrote:
> Note:<commit_id>  parameter assumed as 'HEAD'
>
>    meta/recipes-devtools/perl/perl-5.8.8/config.sh                                     |    8
>    meta/recipes-devtools/perl/perl-5.8.8/perl-enable-gdbm.patch                        |   17 +
>    meta/recipes-devtools/perl/perl_5.8.8.bb                                            |    2
>
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.12-zlib.patch                 |  169 ++++++++++
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-data_types.patch          |   32 +
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-help-index-segfault.patch |   23 +
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-mosdo-crash.patch         |   11
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-powerpc.patch             |   12
>    meta/recipes-extended/texinfo/texinfo_4.13a.bb                                      |   57 +++
>    9 files changed, 327 insertions(+), 4 deletions(-)
>
> Jingdong Lu (2):
>         texinfo: Add new package
>         Fix adding GDBM_File module for LSB test.
>
> Pull URL:
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jingdonglu/distro
>

Re: [PULL]Fix adding GDBM_File module for perl

[Richard Purdie]

On Mon, 2010-11-01 at 14:32 -0500, Mark Hatle wrote:
> I've been doing some thinking about how various perl and related components 
> should be implemented if they do potentially optional things.
> 
> My concern is that by adding gdbm to the build, that other components will 
> change and potentially require more disk space.  We really need a way to 
> optionally use gdbm, if available in these configurations.  I'm really not sure 
> if there is currently a way to tell bitbake:
> 
> I really want gdbm, but if nothing else wants it.. I don't want it.  Then for 
> LSB specific builds, we manually require gdbm as an LSB requirement (due to the 
> gdbm perl module requirements.)
> 
> Richard, any suggestions on how to work with this?

The trouble is the configuration is entirely deterministic by design. At
this point people start talking about Gentoo USE flags and how we should
add them and how wonderful the world would be.

To talk through the use case, I run "bitbake poky-image-sato" which lets
say doesn't need gdbm so perl is built without gdbm.

I then "bitbake poky-image-sdk" which does include it. Does perl get
rebuilt?

Another issue is the perl packages themselves. These can differ
depending on whether gdbm was included or not. If I hand you two perl
package rpms, how do you tell the difference?

Obviously you can mark them somehow or embed data into them but there is
no mechanism for this in some packaging systems. It makes maintenance of
feeds very hard as the build order can drastically change the contents
of the feeds.

One "middle ground" solution I've considered is extended use of the
DISTRO_FEATURES variable. By default this would be a pretty inclusive
list of things like "gdbm". The perl recipe would only include gdbm if
it was included in the list. The user can then customise the
DISTRO_FEATURES list and remove things they don't care about. Presumably
under this scenario, gdbm itself could exit with an error if someone
tried to build it and it wasn't listed.

Checksums will allow us to handle dynamically rebuilding anything that
changes when you edit that variable.

Does that give us a solution that would work for you?

Cheers,

Richard

Re: [PULL]Fix adding GDBM_File module for perl

[Mark Hatle]

On 11/5/10 8:34 AM, Richard Purdie wrote:
> On Mon, 2010-11-01 at 14:32 -0500, Mark Hatle wrote:
>> I've been doing some thinking about how various perl and related components
>> should be implemented if they do potentially optional things.
>>
>> My concern is that by adding gdbm to the build, that other components will
>> change and potentially require more disk space.  We really need a way to
>> optionally use gdbm, if available in these configurations.  I'm really not sure
>> if there is currently a way to tell bitbake:
>>
>> I really want gdbm, but if nothing else wants it.. I don't want it.  Then for
>> LSB specific builds, we manually require gdbm as an LSB requirement (due to the
>> gdbm perl module requirements.)
>>
>> Richard, any suggestions on how to work with this?
>
> The trouble is the configuration is entirely deterministic by design. At
> this point people start talking about Gentoo USE flags and how we should
> add them and how wonderful the world would be.
>
> To talk through the use case, I run "bitbake poky-image-sato" which lets
> say doesn't need gdbm so perl is built without gdbm.
>
> I then "bitbake poky-image-sdk" which does include it. Does perl get
> rebuilt?

In our (WR) environment with the checksums, yes it would get rebuilt as the 
referenced source packages available changes, so the "dynamic build-time 
dependency" set will also change.

> Another issue is the perl packages themselves. These can differ
> depending on whether gdbm was included or not. If I hand you two perl
> package rpms, how do you tell the difference?

We only provide the right set for the filesystem we're constructing.  Obviously 
Poky is different in this regards as there is no single set of available 
packages for a particular build set.. it's all packages.  This is something that 
will have to be figured out.

The only thing that comes to the top of my head right now is the dynamic PR 
numbers in how the git checks do their numbering when things change.  Not 
exactly deterministic though.

> Obviously you can mark them somehow or embed data into them but there is
> no mechanism for this in some packaging systems. It makes maintenance of
> feeds very hard as the build order can drastically change the contents
> of the feeds.
>
> One "middle ground" solution I've considered is extended use of the
> DISTRO_FEATURES variable. By default this would be a pretty inclusive
> list of things like "gdbm". The perl recipe would only include gdbm if
> it was included in the list. The user can then customise the
> DISTRO_FEATURES list and remove things they don't care about. Presumably
> under this scenario, gdbm itself could exit with an error if someone
> tried to build it and it wasn't listed.

I think this is likely the best approach for the way things are done by Poky.  A 
set of known features that have system wide affects.  These features are static 
and allow someone to develop what they want, vs what is "discovered" by the 
dependency mechanisms.

For instance, the following items come to mind as being able to be switched on 
an off "easily" for many systems:

SE Linux
PAM
Berkley DB
gdbm
readline
ncurses
perl
python
Xorg
tcp_wrappers

but unfortunately you start looking at that list, and you think of other things 
like mysql, postgresql, gnutls, openssl... etc..

So whatever mechanism is selected needs to be able to be extended easily.  Even 
if Poky and the Poky recipes don't directly support those extensions, someone 
will want a way to say "I don't want foo", and then in turn go through and 
remove foo from anything that can do it dynamically.

> Checksums will allow us to handle dynamically rebuilding anything that
> changes when you edit that variable.
>
> Does that give us a solution that would work for you?

Ya, the distro_feature list is good.. it gives us a more workable set to develop 
and test against.. but we'll need to have guidelines as to what is appropriate 
(or not) to add to that set.

And similar to the license filtering.. if the functionality is _off_, we should 
also figure out a way to block that component from coming into the build.

--Mark

> Cheers,
>
> Richard
>
>
>

Re: [PULL]Fix adding GDBM_File module for perl

[Saul Wold]

On 11/01/2010 03:22 AM, Lu Jingdong wrote:
> Note:<commit_id>  parameter assumed as 'HEAD'
>
>    meta/recipes-devtools/perl/perl-5.8.8/config.sh                                     |    8
>    meta/recipes-devtools/perl/perl-5.8.8/perl-enable-gdbm.patch                        |   17 +
>    meta/recipes-devtools/perl/perl_5.8.8.bb                                            |    2
>
Jingdong,

We have not forgotten about your changes, we are trying to determine the 
impact of the changes you are suggesting.  Can you please let us know 
what the size difference would of perl by adding this change?  Is it 
just a simple perl module?  What additional dependencies occur when you 
add this patch and their impact on size.

Sau!
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.12-zlib.patch                 |  169 ++++++++++
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-data_types.patch          |   32 +
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-help-index-segfault.patch |   23 +
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-mosdo-crash.patch         |   11
>    meta/recipes-extended/texinfo/texinfo-4.13a/texinfo-4.13a-powerpc.patch             |   12
>    meta/recipes-extended/texinfo/texinfo_4.13a.bb                                      |   57 +++
>    9 files changed, 327 insertions(+), 4 deletions(-)
>
> Jingdong Lu (2):
>         texinfo: Add new package
>         Fix adding GDBM_File module for LSB test.
>
> Pull URL:
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jingdonglu/distro
>

Re: [PULL]Fix adding GDBM_File module for perl

[Lu Jingdong]

On Mon, 2010-11-22 at 10:14 -0800, Saul Wold wrote:
> On 11/01/2010 03:22 AM, Lu Jingdong wrote:
> > Note:<commit_id>  parameter assumed as 'HEAD'
> >
> >    meta/recipes-devtools/perl/perl-5.8.8/config.sh                                     |    8
> >    meta/recipes-devtools/perl/perl-5.8.8/perl-enable-gdbm.patch                        |   17 +
> >    meta/recipes-devtools/perl/perl_5.8.8.bb                                            |    2
> >
> Jingdong,
> 
> We have not forgotten about your changes, we are trying to determine the 
> impact of the changes you are suggesting.  Can you please let us know 
> what the size difference would of perl by adding this change?  Is it 
> just a simple perl module?  What additional dependencies occur when you 
> add this patch and their impact on size.
> 
> Sau!

Saul,
I think there is less influence on perl by enabling gdbm except that we
get a dynamic extend module. We compiled perl with gdbm enabled, we can
get "perl-module-gdbm-file" package and it provides the following files:
/usr/lib/perl/5.8.8/GDBM_File.pm
/usr/lib/perl/5.8.8/auto
/usr/lib/perl/5.8.8/auto/GDBM_File
/usr/lib/perl/5.8.8/auto/GDBM_File/GDBM_File.bs
/usr/lib/perl/5.8.8/auto/GDBM_File/GDBM_File.so

I add dependency of perl "+DEPENDS += "gdbm", because compiling gdbm
module of perl needs the "gdbm.h" provided by gdbm-dev.

-- 
Lu Jingdong
jingdong.lu@windriver.com
China, Wind River