| Summary: | Improve capabilities for updating & extending the SDK after installation | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Joshua Lock - Disabled <josh> |
| Component: | devtools / tool chain | Assignee: | Richard Purdie <richard.purdie> |
| Status: | VERIFIED DUPLICATE | QA Contact: | Alexandru Georgescu <alexandru.c.georgescu> |
| Severity: | enhancement | ||
| Priority: | Medium+ | CC: | alexandru.c.georgescu, bluelightning, bogdanx.a.voiculescu, jessica.zhang, meta.mr.watcher, meta.watcher, poky.bs.watcher, poky.watcher, sgw |
| Version: | 1.7 | ||
| Target Milestone: | 1.7 M2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
|
Description
Joshua Lock - Disabled
2010-07-16 04:57:30 UTC
Currently we put the SDK under package management control. This has a variety of drawbacks and is hard to the central admin/distro engineer to deploy to users, user feedback as not been positive. One alternative proposal is to put the files under control of something more like sstate. The resononing is that sstate is how we solved a very similar problem within the build system itself. There, we set out on a journey with "packaged staging" and ended up throwing away the package maager and using something specifically engineered for the problem. The premise is we have a similar issue here and we'd prefer to get to the better conclusion without the 4 different versions. The advantage of sstate is strong interaction with the main builds by using the same processes (see bug X). Locked sstate is obviously a key part of this proposal. 6559 now has the plans for this *** This bug has been marked as a duplicate of bug 6559 *** Verified as per above comments. |