Hi Jaco,
* we have more stages
* the binary packages have to go somewhere
* and, temporarily, things are duplicated due to the 17.x / 23.0 profile
transition
The third point will eventually go away. However, I'm not sure how much it
actually
contributes.
Wouldn’t initiatives like rust-dev[0] help with that? I know that Debian
is also packaging Rust this way[1].
I think this was tried long time ago in rust-overlay and failed at the
end because the dependency graph was incredibly big. In fact you can see
it on the wiki, this is larger than _the
I guess the simplest explanation is that software is growing larger,
and in the end we should be expecting to adding new packages faster than
removing dead ones. Add to that the grotesque inefficiency of modern
programming languages such as Go and Rust.
Wouldn’t initiatives like rust-dev[0]
On Fri, 2024-03-15 at 10:06 +0200, Jaco Kroon wrote:
> Hi All,
>
> I was messing with some storage related caching on some of our hosts
> this morning when I wondered about how much storage the gentoo mirrors
> were consuming. I'm not too worried about the current storage, but I am
> noticing
Hi All,
I was messing with some storage related caching on some of our hosts
this morning when I wondered about how much storage the gentoo mirrors
were consuming. I'm not too worried about the current storage, but I am
noticing that the storage requirements are creeping quite a bit (as per
