-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jigdo relabeling ineffective for docker/container-selinux #1172
Labels
Comments
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Jan 2, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path for unified core didn't actually have any effect as the core code did a relabel and unset the array. I think this may actually be a regression from: coreos#1137 though I didn't verify. Anyways looking at this, the code is a lot simpler if we change the API so that the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we change the public relabel API to be "force relabel" which we use in the unified core 🌐 treecompose path. This shrinks the jigdoRPM for FAH from 90MB to 68MB. Closes: coreos#1172
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Jan 3, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path for unified core didn't actually have any effect as the core code did a relabel and unset the array. I think this may actually be a regression from: coreos#1137 though I didn't verify. Anyways looking at this, the code is a lot simpler if we change the API so that the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we change the public relabel API to be "force relabel" which we use in the unified core 🌐 treecompose path. This shrinks the jigdoRPM for FAH from 90MB to 68MB. Closes: coreos#1172
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Jan 6, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path for unified core didn't actually have any effect as the core code did a relabel and unset the array. I think this may actually be a regression from: coreos#1137 though I didn't verify. Anyways looking at this, the code is a lot simpler if we change the API so that the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we change the public relabel API to be "force relabel" which we use in the unified core 🌐 treecompose path. This shrinks the jigdoRPM for FAH from 90MB to 68MB. Closes: coreos#1172
rh-atomic-bot
pushed a commit
that referenced
this issue
Jan 8, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path for unified core didn't actually have any effect as the core code did a relabel and unset the array. I think this may actually be a regression from: #1137 though I didn't verify. Anyways looking at this, the code is a lot simpler if we change the API so that the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we change the public relabel API to be "force relabel" which we use in the unified core 🌐 treecompose path. This shrinks the jigdoRPM for FAH from 90MB to 68MB. Closes: #1172 Closes: #1173 Approved by: jlebon
rh-atomic-bot
pushed a commit
that referenced
this issue
Jan 8, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path for unified core didn't actually have any effect as the core code did a relabel and unset the array. I think this may actually be a regression from: #1137 though I didn't verify. Anyways looking at this, the code is a lot simpler if we change the API so that the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we change the public relabel API to be "force relabel" which we use in the unified core 🌐 treecompose path. This shrinks the jigdoRPM for FAH from 90MB to 68MB. Closes: #1172 Closes: #1173 Approved by: jlebon
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I thought I had this working before but perhaps not. Anyways I was doing some analysis on the current 90MB FAHC jigdoRPM:
And of course the problem is:
Reading the code a bit I think the reason this happens is the second
rpmostree_context_relabel()
is a noop as "packages to relabel" is a 0 length array. We need to have anrpmostree_context_force_relabel()
or so?The text was updated successfully, but these errors were encountered: