[wip] tiered cache

[wolfv]

This is a starting point for a tiered cache where one could have multiple package caches, where some of the lower ones might be read-only.

A challenge is that we probably cannot do "read-locking" on read-only caches since we wouldn't be allowed to create lockfiles at all.

Another goal is that we can say: can-reflink or can-symlink per-cache (I want to store a HashMap in the cache with prefix mapping to capabilities).

[kelvinou01]

@wolfv Hello from #1003! I may be missing some context, so I’d appreciate your clarification:

A challenge is that we probably cannot do "read-locking" on read-only caches since we wouldn't be allowed to create lockfiles at all.

Assuming that all packages are fetched via the PackageCache interface, isn't it guaranteed that each package in the cache already has a lockfile? If so, how does that affect the read-locking concern?

Another goal is that we can say: can-reflink or can-symlink per-cache (I want to store a HashMap in the cache with prefix mapping to capabilities).

Could you provide more details on this? I’m not entirely clear on how the can-reflink and can-symlink capabilities would be used per cache.

Thanks!

[wolfv]

@kelvinou01 ah I see. Maybe you are right! I wasn't sure if we could aquire a lock in a read-only filesystem but your argument makes sense. I think if we cannot aquire a lock, we can ignore that, too.

We are linking each package individually, and we are testing wether we can reflink from package cache to target_prefix for each package. Instead of performing this check for every package, we could perform the check once, per package cache, and store this information in the cache.

We have functions that try to create a hardlink or symlink from package cache to prefix already in the link.rs file (I think).