It would be nice to have this feature similarly to "rm_work", but it would remove the latest download accordingly. I keep running out of the space even with using "rm_work". What I need to do every single time is when I get the disk space error, to free up the downloads manually, and that is tedious. Surely, there could be a separate "bitbake -c cleandownloads" feature as well, but that would still require manual intervention which I would personally like to avoid. Yeah, I know everything can be avoided by further man power, such as time and effort, or/and money, but let us state it clearly: there is "rm_work" in there for a reason, already, and suggesting spending more money, effort, and time rather than fixing it in a centralized place is not pragmatic.
Removing the latest download would really hurt when you do a rebuild. Removing older tarballs when you download a new one might be more practical (if trickier).
Not everyone wanna do a rebuild? In addition, there is no better option to get stuff done?
We are clear about the requirements of disk space in the Quick Start guide. As a project the downloads directory and content are preserved to allow for improved build time and allow for off-line builds (or if an upstream experiences networking issues). The project has made this decision, which is why we have the support for disk space monitoring, to remove the working directories, but preserve the downloads and shared state areas in order to have good build times. We can add some documentation about removing the contents of DL_DIR and cleaning shared state and tmp/work areas with a couple of scripts that already exist. As this is not a task we will add, you can, if you wish, create a new bbclass that removes the downloaded tarballs and have it in your layer. It would not require too much effort to write such a bbclass,
Why would I add it myself when it is a reusable feature, and a few people already expressed the interest in my circles... Will you also remove "rm_work" because you are "clear" about the space requirements? As for me, this is claim is first of all, inconsistent, secondly making users' life hard if it is not propagated to the right layer.
Please provid a solution to this issue since we're really short on resource to fullfil it based on priorities on other features that have high demand and solid usage model. Thx.
RESOLVED is an invalid state for an unresolved bug report (feature request to be precise) in my opinion.