| Summary: | devtool: add ability to export / import work in progress | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Paul Eggleton <bluelightning> |
| Component: | Scripts and Tools | Assignee: | Leonardo Sandoval Gonzalez <leonardo.sandoval.gonzalez> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium+ | CC: | leonardo.sandoval.gonzalez, ross.burton |
| Version: | 2.2 | ||
| Target Milestone: | 2.4 M3 | ||
| 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: | 11737 | ||
|
Description
Paul Eggleton
2016-10-27 19:10:17 UTC
M2 missed. Targeting for current milestone. (In reply to comment #0) > Enable basic collaboration by allowing the user to export one, several or > all recipes from their workspace to a single file (tarball?) so that they > can be imported by someone else also using devtool. Sources should be > included in the tarball if they are in the workspace, at least by default. Paul, for the export: I believe the easiest is to find those files related to a specific recipe or recipes and create a tar based on this for the import: based on the above tar file, just untar it skipping those that workspace files that can be overwrite If this is what you want, I believe devtool export/import plugins would act as a simple tar wrappers. I wait for your comments before proceeding. Yes, that's part of it - we also need to ensure that the relevant entries in the .devtool_md5 get exported and imported as well. It also occurs to me that it's possible that user A does an export of a recipe and then user B tries to import that on their system with incompatible metadata - i.e. where the version is different or the recipe is not even available. If we're importing a bbappend, we should check that the bbappend is still applicable (i.e. that a matching recipe exists in the user's configuration) and error out if that's not the case. (In reply to comment #3) > Yes, that's part of it - we also need to ensure that the relevant entries in > the .devtool_md5 get exported and imported as well. > > It also occurs to me that it's possible that user A does an export of a > recipe and then user B tries to import that on their system with > incompatible metadata - i.e. where the version is different or the recipe is > not even available. If we're importing a bbappend, we should check that the > bbappend is still applicable (i.e. that a matching recipe exists in the > user's configuration) and error out if that's not the case. Paul, I realized that this work deserves a separate bug (devtool import being a bit more smart). I will file bug once the following series have been reviewed so direction is clear: http://lists.openembedded.org/pipermail/openembedded-core/2017-May/137140.html Several comments from Paul, requiring a full revision of proposed pluings, so moving it to the next milestone. New series revision sent to review (this is the v4): http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138887.html Patches are in the ML, just did not arrive to master yet. Moving to M3. With some changes from Paul on the proposed patches, finally landed to master. 2de8ba89ef: Leonardo Sandoval: Mon Aug 21 08:30:32 2017 +0100: devtool: import: new plugin to import the devtool workspace f9bc3b5101: Leonardo Sandoval: Mon Aug 21 08:30:32 2017 +0100: devtool: export: new plugin to export the devtool workspace |