| Summary: | devtool: upgrade: report diff for changed files referred to by LIC_FILES_CHKSUM | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Alexander Kanavin <alex.kanavin> |
| Component: | Scripts and Tools | Assignee: | Alexander Kanavin <alex.kanavin> |
| Status: | RESOLVED FIXED | QA Contact: | yeoh ee peng <ee.peng.yeoh> |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | bluelightning, ee.peng.yeoh, maxin.john, nagarajagopalx.velu, poky.bs.watcher, poky.watcher, rebecca.swee.fun.chang, richard.purdie, ross.burton, sgw, shashwatx.pandey, stanley.cheong.kwan.phoong |
| Version: | 2.3 | ||
| Target Milestone: | 2.5 M1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
| Bug Depends on: | |||
| Bug Blocks: | 12360 | ||
|
Description
Alexander Kanavin
2016-12-13 13:19:20 UTC
While agreeing that this is a good idea, some projects (eg: libunistring) updates licenses in totally different files once it changes the effective license of the Project. In the case of libunistring update, it left the two license files that we track in recipe unchanged (COPYING, COPYING.LIB) and updated the effective license in two different files (README, doc/libunistring.texi). We can track these kind of changes only by reading the release notes. http://lists.openembedded.org/pipermail/openembedded-core/2016-December/130051.html COPYING* files themselves do not always set the effective license, but merely provide the license terms for reference (particularly the GPL type stuff). In that case we also need to track a README or some source code file where the license is actually established. libunistring was missing those other files - and that's a different issue. I'm not sure the build system has the information needed to show this diff. We have the new file, but where will it get the old file? The metadata has been changed so that we're fetching the new source rather than the old one. Honestly I think this kind of thing is better handled within tools that help you to update recipes, such as the AUH and devtool upgrade. I believe the AUH already provides a diff, and it's on my todo list for devtool upgrade (perhaps we should have a bug for the latter, maybe this one can be repurposed). That's fine with me. Paul, do you want to take the bug then? Apparently AUH will start using devtool in the future, so that all upgrade functionality is in one place without duplication. OK, repurposing this bug. Accordingly the spec should be: When devtool upgrade runs on a recipe, if any files referred to by LIC_FILES_CHKSUM have changed then report the difference. I suspect what we'll need to do is write out a separate diff file, show a message, and also include a comment in the recipe reminding the user that they need to check the diff. One catch with this is that it is possible (though not too common) for those files not to be ready to look at until the end of do_configure - that's when the check runs. We perhaps may ignore that corner case for now but we should be aware of it. I'm actually not sure how widespread it is - I assume it's indended to take care of recipes where you make a license choice at configure time. What is the current status with this issue? Paul, shall I reassign it to you? Hi Alexander, sorry was cooped up with some critical work over the last few weeks. Hoping to close this bug by next week. Thanks for the reminder :) md5 LICENSE checksum is not updating in new recipe after devtool upgrade. debugged and try to find the issue in /scripts/lib/devtool/upgrade.py and /scripts/lib/recipetool/create.py.but, unable to fix the issue. Just for clarification - this isn't a bug, it's a missing feature. devtool upgrade needs to be changed to find the license files, compare them, update LIC_FILES_CHKSUM (which it doesn't do at the moment) and report the diff to the user as described above. A patch has been already pushed to mailing list. http://lists.openembedded.org/pipermail/openembedded-core/2017-November/145000.html |