rpm-ostree install vim-common fails with EEXIST #1047
Comments
jlebon
added a commit
to jlebon/ostree
that referenced
this issue
Oct 10, 2017
There's a subtle issue going on with the way we use `UNION_IDENTICAL` now in rpm-ostree. Basically, the crux of the issue is that we checkout the whole tree from the system repo, but then overlay packages by checking out from the pkgcache repo. This is an easy way to break the assumption that we will be merging hardlinks from the same repo. This ends up causing issues like: coreos/rpm-ostree#1047 There, `vim-minimal` is already part of the host and has an object for `/usr/share/man/man1/ex.1.gz`. `vim-common` has that same file, but because it's unpacked in the pkgcache repo first, the hardlinks are not the same. There are a few ways we *could* work around this in rpm-ostree itself, e.g. by re-establishing hardlinks when we do the content pull into the system repo, but it still felt somewhat hacky. Let's just do this the proper way and fall back to checksumming the target file if needed, which is what librpm does as well in this case. Note that we only checksum if they're not hard links, but they're the same size.
This was referenced Oct 10, 2017
jlebon
added a commit
to jlebon/ostree
that referenced
this issue
Oct 11, 2017
There's a subtle issue going on with the way we use `UNION_IDENTICAL` now in rpm-ostree. Basically, the crux of the issue is that we checkout the whole tree from the system repo, but then overlay packages by checking out from the pkgcache repo. This is an easy way to break the assumption that we will be merging hardlinks from the same repo. This ends up causing issues like: coreos/rpm-ostree#1047 There, `vim-minimal` is already part of the host and has an object for `/usr/share/man/man1/ex.1.gz`. `vim-common` has that same file, but because it's unpacked in the pkgcache repo first, the hardlinks are not the same. There are a few ways we *could* work around this in rpm-ostree itself, e.g. by re-establishing hardlinks when we do the content pull into the system repo, but it still felt somewhat hacky. Let's just do this the proper way and fall back to checksumming the target file if needed, which is what librpm does as well in this case. Note that we only checksum if they're not hard links, but they're the same size.
jlebon
added a commit
to jlebon/ostree
that referenced
this issue
Oct 12, 2017
There's a subtle issue going on with the way we use `UNION_IDENTICAL` now in rpm-ostree. Basically, the crux of the issue is that we checkout the whole tree from the system repo, but then overlay packages by checking out from the pkgcache repo. This is an easy way to break the assumption that we will be merging hardlinks from the same repo. This ends up causing issues like: coreos/rpm-ostree#1047 There, `vim-minimal` is already part of the host and has an object for `/usr/share/man/man1/ex.1.gz`. `vim-common` has that same file, but because it's unpacked in the pkgcache repo first, the hardlinks are not the same. There are a few ways we *could* work around this in rpm-ostree itself, e.g. by re-establishing hardlinks when we do the content pull into the system repo, but it still felt somewhat hacky. Let's just do this the proper way and fall back to checksumming the target file if needed, which is what librpm does as well in this case. Note that we only checksum if they're not hard links, but they're the same size.
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Oct 13, 2017
We originally needed the pkgcache to be a separate repo due to ostree's overzealous pruning policies. The idea was to maintain multiple commits in each pkg branch for different SELinux policies. In practice, there's not much use in maintaining old copies and it's just easier to always relabel on the fly. So then, the need for a separate repo completely melts away. This helps simplify the core a bunch and just generally makes it more pleasant to work with. It also allows us to avoid subtle issues like coreos#1047. The tricky bit is migrating the cache. In theory, we only really need to migrate local RPM overrides/overlays, but if we're going to build support for that, we might as well migrate it all. We do this by checking at key points where the cache will be used whether a migration is necessary. After migrating once, it boils down to one `fstatat()` on subsequent runs to check that the repo no longer exists.
rh-atomic-bot
pushed a commit
to ostreedev/ostree
that referenced
this issue
Oct 14, 2017
There's a subtle issue going on with the way we use `UNION_IDENTICAL` now in rpm-ostree. Basically, the crux of the issue is that we checkout the whole tree from the system repo, but then overlay packages by checking out from the pkgcache repo. This is an easy way to break the assumption that we will be merging hardlinks from the same repo. This ends up causing issues like: coreos/rpm-ostree#1047 There, `vim-minimal` is already part of the host and has an object for `/usr/share/man/man1/ex.1.gz`. `vim-common` has that same file, but because it's unpacked in the pkgcache repo first, the hardlinks are not the same. There are a few ways we *could* work around this in rpm-ostree itself, e.g. by re-establishing hardlinks when we do the content pull into the system repo, but it still felt somewhat hacky. Let's just do this the proper way and fall back to checksumming the target file if needed, which is what librpm does as well in this case. Note that we only checksum if they're not hard links, but they're the same size. Closes: #1258 Approved by: cgwalters
|
This was fixed by ostreedev/ostree#1258. |
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Nov 20, 2017
We originally needed the pkgcache to be a separate repo due to ostree's overzealous pruning policies. The idea was to maintain multiple commits in each pkg branch for different SELinux policies. In practice, there's not much use in maintaining old copies and it's just easier to always relabel on the fly. So then, the need for a separate repo completely melts away. This helps simplify the mental model a bit and allows us to avoid subtle issues like coreos#1047. Note however that the core is still capable of handling split repos for the `--ex-unified-core` compose use case. Once that and the jigdo work are a bit more settled, we can have a clearer picture of how to simplify the core further. The tricky bit is migrating the cache. At daemon startup, we check if a pkgcache repo exists and migrate its refs if so. This does mean that rolling back to a tree with an older rpm-ostree and deploying from there will require e.g. redownloading RPMs and reproviding any local RPMs to layer. In such situations, we ensure that when eventually re-upgrading from a newer rpm-ostree, we prioritize those newer refs.
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Nov 28, 2017
We originally needed the pkgcache to be a separate repo due to ostree's overzealous pruning policies. The idea was to maintain multiple commits in each pkg branch for different SELinux policies. In practice, there's not much use in maintaining old copies and it's just easier to always relabel on the fly. So then, the need for a separate repo completely melts away. This helps simplify the mental model a bit and allows us to avoid subtle issues like coreos#1047. Note however that the core is still capable of handling split repos for the `--ex-unified-core` compose use case. Once that and the jigdo work are a bit more settled, we can have a clearer picture of how to simplify the core further. The tricky bit is migrating the cache. When deploying, we check if a pkgcache repo exists and migrate its refs if so. We then leave behind a symlink to the system repo to remain compatible with older rpm-ostrees.
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Nov 29, 2017
We originally needed the pkgcache to be a separate repo due to ostree's overzealous pruning policies. The idea was to maintain multiple commits in each pkg branch for different SELinux policies. In practice, there's not much use in maintaining old copies and it's just easier to always relabel on the fly. So then, the need for a separate repo completely melts away. This helps simplify the mental model a bit and allows us to avoid subtle issues like coreos#1047. Note however that the core is still capable of handling split repos for the `--ex-unified-core` compose use case. Once that and the jigdo work are a bit more settled, we can have a clearer picture of how to simplify the core further. The tricky bit is migrating the cache. When deploying, we check if a pkgcache repo exists and migrate its refs if so. We then leave behind a symlink to the system repo to remain compatible with older rpm-ostrees.
rh-atomic-bot
pushed a commit
that referenced
this issue
Dec 1, 2017
We originally needed the pkgcache to be a separate repo due to ostree's overzealous pruning policies. The idea was to maintain multiple commits in each pkg branch for different SELinux policies. In practice, there's not much use in maintaining old copies and it's just easier to always relabel on the fly. So then, the need for a separate repo completely melts away. This helps simplify the mental model a bit and allows us to avoid subtle issues like #1047. Note however that the core is still capable of handling split repos for the `--ex-unified-core` compose use case. Once that and the jigdo work are a bit more settled, we can have a clearer picture of how to simplify the core further. The tricky bit is migrating the cache. When deploying, we check if a pkgcache repo exists and migrate its refs if so. We then leave behind a symlink to the system repo to remain compatible with older rpm-ostrees. Closes: #1055 Approved by: cgwalters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Split from #415 because I believe they're separate issues:
Like @kallisti5 above, I ran into the problem with
vim-common. (Going to paste my session here for searchability later)The text was updated successfully, but these errors were encountered: