On Fri, 2013-11-15 at 11:31 +0800, Robert Yang wrote: > Currently, the recipe which uses PACKAGES_DYNAMIC usually generates > a lot of packages which costs a lot of time on building the recipe > and do_rootfs, for example, the perl and kernel: > > $ ls tmp/deploy/rpm/armv5te/perl-module-* | wc -l > 621 > > $ ls tmp/deploy/rpm/qemux86/kernel-module-* | wc -l > 268 > > Also, the eglibc-locale generates more than 300 packages. > > Take perl as an example: > > 1) We generate 621 perl-module-* packages, but the package *perl-modules* > requires all of them, so once *perl-modules* is installed, all the other > perl-module-* will be installed and we can't remove any of them since > perl-modules rdepends on it, if there is a way to package all of these > perl-module-* into one package (they are about 10MB), it would save a lot > of time on do_package* and do_rootfs. > > 2) The nativesdk.bbclass can't support PACKAGES_DYNAMIC, for example, it can't > change the perl-module-app-cpan to nativesdk-perl-module-app-cpan since > there is no perl-module-app-cpan in PACKAGES when nativesdk.bbclass > changes the variable's name. > > Can we add a way to let the PACKAGES_DYNAMIC be optional ? for example, > > PACKAGES_DYNAMIC[perl] = "0" > > will disable the perl's PACKAGES_DYNAMIC, and will pack the files as other > recipes do, and of course we need to do some work on the recipe.
Before we consider doing this, I'd actually like to see real numbers about how big this problem is. Why? Speaking as someone who has looked specifically at perl and the kernel, I don't believe there is a huge amount of time spent dealing with the individual packages and that maintaining two build paths is actually worse than they minimal performance impact this has. In particular, I'd note that the locale generation happens in parallel with other parts of the build and is not a significant factor in overall build times. The time would be better spent reducing the size of the kernel source installed into the sysroot for example (Bruce is planning action on this). Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
