Bug 8764 - Add an easy to use script like AUH (auto upgrade help)
Summary: Add an easy to use script like AUH (auto upgrade help)
Status: RESOLVED WONTFIX
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: Scripts and Tools (show other bugs)
Version: 2.1
Hardware: x86 Multiple
: Undecided enhancement
Target Milestone: 2.1 M2
Assignee: Robert Yang
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2015-12-04 03:02 UTC by Robert Yang
Modified: 2015-12-11 01:51 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Yes (doc changes required)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Yang 2015-12-04 03:02:43 UTC
Add a script which is used for upgrading recipe locally, which can:
1) Easy to run locally, for example add it to poky/scripts
2) It can edit the recipe simply, for example rename the recipe, update checksum
3) It can check whether all PACKAGECONFIG works (not only the default ones), it it doesn't work because of lacks of DEPENDS, then that's fine since not all the dependencies are in oe-core, otherwise, bugs.
4) It can check whether its depends are right (doing fresh build)
5) It can build core-image-sato populate_sdk and world when requested.
Comment 1 Paul Eggleton 2015-12-07 04:51:21 UTC
FYI 1 & 2 can be done by "devtool upgrade" right now.

Also the AUH is designed to be able to be run standalone, although it's not the primary use case.
Comment 2 Richard Purdie 2015-12-10 15:44:07 UTC
I'm a little bit concerned about duplication here. As Paul mentions, devtool upgrade already covers some of this for 1 and 2.

For 3, I'm worried that testing each PACKAGECONFIG would cause problems when you consider something large like mesa so that may not be feasible.

For 4, Martin has done some similar work but wouldn't we want to enhance the AUH code to handle this?

I'd also like to understand why we need a new script when we have AUH and devtool. What is the usecase for something in addition to just enhancing those?
Comment 3 Paul Eggleton 2015-12-10 20:25:59 UTC
I'd also note that my hope is that in future there will be more sharing of code between the AUH and "devtool upgrade" so that even that effective duplication goes away.
Comment 4 Robert Yang 2015-12-11 01:51:06 UTC
Sorry, I don't know much about AUH, if AUH can do some similar work, then I will close this one.