Bug 5635 - Changing LICENSE_CREATE_PACKAGE doesn't always take effect
Summary: Changing LICENSE_CREATE_PACKAGE doesn't always take effect
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 1.5
Hardware: x86 Multiple
: Medium normal
Target Milestone: 2.1 M3
Assignee: Ross Burton
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-12-06 07:43 UTC by Chen Qi
Modified: 2016-02-08 15:58 UTC (History)
8 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chen Qi 2013-12-06 07:43:16 UTC
problem
-------
Enabling and disabling 'LICENSE_CREATE_PACKAGE' doesn't cause rerun of the packaging process. As a result, if this variable is first enabled when building an image, and is then disabled when rebuilding the image, the license packages (e.g. busybox-lic) are still installed into that image. This is obviously not desired.

To reproduce, use the following steps:
1. set in local.conf:
LICENSE_CREATE_PACKAGE = "1"
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
2. bitbake busybox
3. set in local.conf:
# LICENSE_CREATE_PACKAGE = "1"
# COPY_LIC_MANIFEST = "1"
# COPY_LIC_DIRS = "1"
4. bitbake busybox

Use the following command to verify that the license package is still required by the main busybox pacakge.
rpm -qp --requires <path/to/busybox/rpm/package> | grep '\-lic'


cause
-----
The license copying process should be in do_install task instead of the do_package task. This is because that copying of license has effect on ${D} instead of ${PKGD}.

//Chen Qi
Comment 1 Chen Qi 2014-11-11 02:03:53 UTC
Nobody cares about this one. Close it.
Comment 2 Joshua Lock 2016-02-03 15:50:21 UTC
Stumbled on this when helping get docs written for the LICENSE_CREATE_PACKAGE variable in #8633
Comment 3 Ross Burton 2016-02-03 16:37:52 UTC
Patch on the list.
Comment 4 Ross Burton 2016-02-08 15:58:04 UTC
Fixed in oe-core master 0450c74e36b5547e3e903fdabe0f52675ac94dea.