Hi Alice,
AFAIK, this doesn't exist so far. I personally would really appreciate to have such a tool at hand but don't have the time to dive into it currently. However, I suspect that this kind of tool is part of a complete new abstraction layer (software management) on top of the current rather manual/low-level depot management (and not a mere addition to the latter) because I see other tasks connected to it like detecting and applying updates of packages in the "installed list" and managing the "installed list".
Cheers, Martin
On 08.03.23 11:27, Alice Domage wrote:
Dear Genodians,
With the democratization of Goa and the direction we are taking to use it more often in our workflow, we extensively create, upload, download, extract, and deploy PKGs on our devices. Inevitably, we filled up our storage with the depot, most notably on our arm_v8a-based gateway that only comes with 16Gb of eMMC. We need a strategy to clearly define what can be removed from the device and do it accordingly. I have sketched out a plan for implementing this feature and would like your opinion on that. Also, would you be interested in taking this upstream?
I want to create a new component, 'depot_autoremove', that would be executed by the 'depot_download_manager' after the 'extract' step as an optional stage. The 'depot_autoremove' component will consume a config, the installation config, to identify a set of packages to keep installed. It will remove any other packages and orphan dependencies not part of that set.
That would be the first iteration for this component.
You may have already thought about this problem and might have an idea of how to solve it.
- Is there already an existing solution to this problem that I have
overlooked? 2. Is there an alternative approach that you would be more in favour of? 3. What is your opinion on this approach?
Best, Alice Domage
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users