You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’ve had problems caused by running the public hermit and our internal hermit on the same machine. In particular, some package names collide, so we get the public OpenJDK when expecting our internal packaging of OpenJDK.
I’d like for Hermit to prevent such collisions from causing us grief. Perhaps by namespacing packages on the filesystem using a hash? Instead of pkg/k9s-0.27.4/ it would be something like pkg/9s-0.27.4-a5c4faa30.
We’re currently working around this problem by setting an environment variable on CI builds where this problem is most pronounced:
I started implementing this today, and there are a couple of complications.
Implementing this will effectively result in all existing packages on an individual machine being reinstalled.
I think this could be mitigated somewhat by adding some special-casing to delete any existing packages that don't include hashes, but maybe it's not worth the hassle.
Package resolution occurs quite frequently in Hermit (eg. every time a binary is executed), and this change will slow that down due to the hashing of the package itself and any files that it copies during installation.
It's not clear to me how much of an impact this would be in practice, I'll have to do some testing. There's currently no caching either, so that could be an easy win.
Other than these considerations, it seems fairly straightforward.
spicykay
pushed a commit
to spicykay/hermit
that referenced
this issue
Aug 23, 2024
My company uses a private internal-only Hermit.
We’ve had problems caused by running the public hermit and our internal hermit on the same machine. In particular, some package names collide, so we get the public OpenJDK when expecting our internal packaging of OpenJDK.
I’d like for Hermit to prevent such collisions from causing us grief. Perhaps by namespacing packages on the filesystem using a hash? Instead of
pkg/k9s-0.27.4/
it would be something likepkg/9s-0.27.4-a5c4faa30
.We’re currently working around this problem by setting an environment variable on CI builds where this problem is most pronounced:
The text was updated successfully, but these errors were encountered: