| Summary: | Add --dist-clean, --force, or some other flag to 'devtool reset' to clean all recipe cruft | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Brian Kurle <brianx.j.kurle> |
| Component: | devtools / tool chain | Assignee: | Unassigned <unassigned> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | meta.mr.watcher, meta.watcher, randy.macleod, sgw |
| Version: | 2.4 | ||
| Target Milestone: | 5.99 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | . | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
|
Description
Brian Kurle
2017-04-24 22:39:55 UTC
I'd avoided adding an option like this particularly with regard to the source tree for fear of users getting in the habit of using it every time until that one day when they forget to save their work within the source tree, and then devtool complies and trashes it. Then again, they could just as easily rm -rf it as instructed and end up in the same situation. However, even if we do go ahead and add it, I would like to try to avoid users needing to use this option as much as possible by fixing any issues caused by cruft hanging around. Other than the annoyance of sources/<recipe> triggering an error when repeating the same devtool add, any warnings you get about files in the attic, and bug 11407, are there any other issues you have hit because of files being left around that this option would clear out? I've occasionally encountered inexplicable build errors and reconfiguration problems. Generally it is from getting a recipe or command incorrect (e.g., wrong URL), attempting to reset the recipe in the workspace and redoing it. The desire is to make the environment pristine for just the recipe desired (or all if -a) without blowing away the entire eSDK (or chasing all the caches to selectively remove), reinstall and rebuild. If it was only a couple locations to remove, I'd have been fine. As I started writing a script to clean the caches and various other locations, I thought it be better if it was included in devtool, itself. Use cases: Working through steps to refine a demo example workflow for a team. Similarly, reworking steps (and correcting errors in steps) for documentation on examples relevant to a team project. (both variants being where I've encountered these problems). The very nicety of the cache can come back to haunt you when you don't expect it (e.g., wrong URL, but same filename in URL). I appreciate not wanting users to shoot themselves in the foot, but there are uses for the -f (even with rm, cp, mv, ln, et al.) The parameter shouldn't be a normal use case (as -f in most cases isn't normal), but one for the exceptional cases. I would argue that requiring the user to explicitly state they wish to shoot their foot off is acceptable as you can point back to the command issued and state you accepted the terms and consequences thereof. We many not want fix this one for the reasons Paul mentioned in comment 1. We have to be careful with user data! Bulk move from 4.99 or 0.00 to 5.99 bulk change to add Saul's non-WR address. Bulk change: Remove Saul's old WR address. |