From: Robert Yang <liezhi.yang@windriver.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: [RFC] let PACKAGES_DYNAMIC be optional ?
Date: Fri, 15 Nov 2013 11:31:18 +0800 [thread overview]
Message-ID: <52859586.5040001@windriver.com> (raw)
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.
--
Thanks
Robert
next reply other threads:[~2013-11-15 3:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-15 3:31 Robert Yang [this message]
2013-11-15 12:18 ` [RFC] let PACKAGES_DYNAMIC be optional ? Richard Purdie
2013-11-15 13:25 ` Otavio Salvador
2013-11-18 8:30 ` Robert Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52859586.5040001@windriver.com \
--to=liezhi.yang@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.