* [PULL]Fix adding GDBM_File module for perl @ 2010-11-01 10:22 Lu Jingdong 2010-11-01 18:19 ` Saul Wold ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Lu Jingdong @ 2010-11-01 10:22 UTC (permalink / raw) To: poky 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PULL]Fix adding GDBM_File module for perl 2010-11-01 10:22 [PULL]Fix adding GDBM_File module for perl Lu Jingdong @ 2010-11-01 18:19 ` Saul Wold 2010-11-01 19:32 ` Mark Hatle 2010-11-22 18:14 ` Saul Wold 2 siblings, 0 replies; 7+ messages in thread From: Saul Wold @ 2010-11-01 18:19 UTC (permalink / raw) To: poky 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PULL]Fix adding GDBM_File module for perl 2010-11-01 10:22 [PULL]Fix adding GDBM_File module for perl Lu Jingdong 2010-11-01 18:19 ` Saul Wold @ 2010-11-01 19:32 ` Mark Hatle 2010-11-05 13:34 ` Richard Purdie 2010-11-22 18:14 ` Saul Wold 2 siblings, 1 reply; 7+ messages in thread From: Mark Hatle @ 2010-11-01 19:32 UTC (permalink / raw) To: poky 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PULL]Fix adding GDBM_File module for perl 2010-11-01 19:32 ` Mark Hatle @ 2010-11-05 13:34 ` Richard Purdie 2010-11-05 16:14 ` Mark Hatle 0 siblings, 1 reply; 7+ messages in thread From: Richard Purdie @ 2010-11-05 13:34 UTC (permalink / raw) To: Mark Hatle; +Cc: poky 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PULL]Fix adding GDBM_File module for perl 2010-11-05 13:34 ` Richard Purdie @ 2010-11-05 16:14 ` Mark Hatle 0 siblings, 0 replies; 7+ messages in thread From: Mark Hatle @ 2010-11-05 16:14 UTC (permalink / raw) To: Richard Purdie; +Cc: poky 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 > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PULL]Fix adding GDBM_File module for perl 2010-11-01 10:22 [PULL]Fix adding GDBM_File module for perl Lu Jingdong 2010-11-01 18:19 ` Saul Wold 2010-11-01 19:32 ` Mark Hatle @ 2010-11-22 18:14 ` Saul Wold 2010-11-24 5:05 ` Lu Jingdong 2 siblings, 1 reply; 7+ messages in thread From: Saul Wold @ 2010-11-22 18:14 UTC (permalink / raw) To: Lu Jingdong; +Cc: poky 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PULL]Fix adding GDBM_File module for perl 2010-11-22 18:14 ` Saul Wold @ 2010-11-24 5:05 ` Lu Jingdong 0 siblings, 0 replies; 7+ messages in thread From: Lu Jingdong @ 2010-11-24 5:05 UTC (permalink / raw) To: Saul Wold; +Cc: poky 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-11-24 5:03 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-01 10:22 [PULL]Fix adding GDBM_File module for perl Lu Jingdong 2010-11-01 18:19 ` Saul Wold 2010-11-01 19:32 ` Mark Hatle 2010-11-05 13:34 ` Richard Purdie 2010-11-05 16:14 ` Mark Hatle 2010-11-22 18:14 ` Saul Wold 2010-11-24 5:05 ` Lu Jingdong
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.