Luca Bruno

I'm lacking some details here, so just some quick observations: * this seems to be an actual ACI, so not going through docker2aci. On the other hand, still I think...

Late followup on this: a better behavior here would be to having a fail-restarting bootkube unit. However that unit is a `oneshot` service which doesn't support restarts. Changing this to...

I think this is happening because there are no explicit lifetime constraints between the actor and the future, so it automatically gets a `'static` one. On the other hand, the...

While looking into the rpm-ostree issue, we found out that PackageKit also carries some vars_dir [logic](https://github.com/PackageKit/PackageKit/blob/30bb82da8d4161330a6d7a20c9989149303421a1/backends/dnf/pk-backend-dnf.c#L175-L184) which does not expect libdnf to internally do any prefixing: ``` dnf_context_set_install_root (context, destdir);...

Looking at the two cases above from distinct projects/developers, they seem to share some common expectations: * `dnf_context_set_repos_dir()` and `dnf_context_set_vars_dir()` are mostly symmetrical APIs, so they are naturally expected to...

I think I found one more case in `microdnf` [logic](https://github.com/rpm-software-management/microdnf/blob/7b84c0699311839ea79b0cfbcbf88ef91e3c0ce1/dnf/dnf-main.c#L218-L229), where the code does handle repos-dir and vars-dir in the same way: ``` else if (strcmp (setopt[0], "reposdir") == 0)...

Additionally, @jrohel noted in https://github.com/PackageKit/PackageKit/pull/369#issuecomment-580707144: > If new empty installation root is processed there is nothing inside. So, it is about use case. Sometime we want to use configuration from...

To the best of my understanding, existing software is already written with the expectation that `libdnf` behaves in the way that this PR does. Prefixing get performed by the consumer,...

> I suspect that when you say "multi-user setup", you mean something quite different, like the ability to host security_monkey as a service and have different users monitor their own...

I agree, it looks like it needs a completely different implementation. Just for the sake of clarity, I'd call this "group membership" (where GroupA can access AccountA1, AccountA2, etc.) because...