split base/layered versionlocked package problem (krb5-workstation) #415
Comments
Isn't this completely up to the content provider, though? Doesn't seem like something we can do much about in |
|
I think if we provided the infrastructure to link to the rpm-md repos from the ostree commit, infra providers could use that. We basically have all the data already from the treecompose side. The infra provider would need to retain multiple versions of the rpm-md repo data though. That said I think the general solution to this is to relax the strict version requirements. |
|
Hit this again today trying to layer And at the time: |
|
doesn't this problem go away if we can replace content in the base layer? #485 |
|
I think we should definitely allow it, but doing that invalidates the concept that the tree is tested and run as a unit. I'm not sure I'd want it to just happen by default. Particularly in this case, it turned out the problem is I was being served a very out of date (rpm-md) mirror. |
right, but don't we invalidate that when we allow package layering at all? I know technically we are just "adding to" rather than "changing" but adding things breaks things sometimes too. Maybe for base package overrides we default to spitting out a message about the fact that this transaction will override a base package and thus the integrity of the tree may suffer and then allow the user to (y/n). Also provide a cli flag for forcing this. |
|
Another good example of this is |
|
Seeing this here as well with vim... this is a painful bug. |
|
Like @kallisti5 above, I ran into the problem with |
|
Right, this is the same issue though the output is different because v2017.9 has #974. A hacky workaround is to manually download the matching vim packages (https://koji.fedoraproject.org/koji/buildinfo?buildID=969318) and locally install that. Hacky because on the next upgrade that bumps |
|
This problem will be comprehensively fixed by jigdo ♲📦 #1081 because the rpm-md and ostree commit will move at the same cadence by default. |
Can you explain this a little more? if yesterday's bodhi run had a new fedora-atomic-host rpm in it (i.e. a new release), and today's run includes new packages (and new base packages that are deps) then won't an rpm-ostree install still fail in the same way if a base package is part of the update? |
|
The jigdoRPM should be generated from the same rpm-md reposet as contains it. That's how it works today in FAHC. |
|
Yes, this means you need to do: |
|
But that still means you need to update to the new jigdoRPM first, right? (Which also assumes that there's a new jigdoRPM to update to). Just like OSTree mode right now? Jigdo does improve the situation in the sense that, at the moment that the jigdoRPM is released, it is in sync with the rest of the RPMs, which is not a guarantee right now. But otherwise, this split issue is still something people can hit, right? |
yeah I figured that much. Specifically for this issue, though, tomorrows bodhi run fires and no new fedora-atomic-host rpm is in that, now there are newer rpms in the rpm-md than what was used to build the fedora-atomic-host rpm and we have this same problem all over again? |
Yes, but we do that by default on
I don't quite understand that. Again the design is that the jigdoRPM is contained within and versioned by the rpm-md repo. The jigdoRPM should be regenerated whenever the RPM content changes. However what you may be getting at here is that today the |
Right, assuming that all Bodhi updates are batched and each batch has a jigdoRPM, then there's no issue. But e.g. right now for FAH, we release every two weeks. Whereas Bodhi batches are every week, right? So there's potentially a one week window during which we can get mismatches. Isn't that the same issue we're hitting right now with the stable vs updates ref? |
Let me explain. Today we have the stable ref |
yes, i think so |
Yes; making full use of jigdo requires that we synchronize those in actuality. |
|
I see two paths:
|
|
Alternatively, we could also add a kind of |
Yeah true, but I really like the protection we have today against the depsolver deciding to swap out something from the base by default. By default we shouldn't offer depsolve errors and a magic switch "make it work" right? |
|
Ok, just so i'm clear on everything.
Some more responses:
This takes us back to where we were before we 'slowed down' the cadence. Not saying that is a bad thing, but it is different.
The problem with this is we don't get all of the rpms from the vast ecosystem that is Fedora. Is there a solution to this that would allow us to keep pulling rpms from the Everything package set but still have a subset of rpms in a separate repo? |
yeah that would be nice
Then we just make it not an option and upgrade the user by default just like in rojig. Solves the same problem. Then all that's left is the updates vs updates-testing problem mentioned above. |
although I think this would render |
|
Edit: this actually seems to be a problem with the repository itself, libxcrypt-devel-4.4.2-3.fc29 is claimed to be not available at all, although it is available on koji: #1724 It would be useful if I tried using Finally I pinned the current deployment, uninstalled all layers, upgraded, used However it still doesn't show which package in the base packages would be the problem... Here is my current status: Edit: in this case the problem was Note that |
|
I'm seeing this when trying to install gcc on Atomic host 29.20190219.0: As soon as the update repos get out of sync from the latest base layer, installing some RPMs becomes impossible. ( Until a real fix is implemented, would it help to build Atomic host base layers with a nightly cadence? |
That exists; just (But I'd recommend doing development in a container, not the host) |
|
@cgwalters Thanks! Rebasing to the updates base layer helped. (Re development in container i agree, we're perhaps using Atomic in a weird way here. We're trying to make a multi-user workstation without forcing everyone to work in containers all the time. We picked Atomic mainly because multiple users have admin rights on the machine, and in this situation Atomic should accumulate less bit rot over time than traditional distros.) |
@jistr - I do want to point out that using the updates base layer ( |
This will be solved by #2125. |
|
Let's close this one because ultimately it's a problem solved at the distro/releng level, not something that rpm-ostree can do a whole lot about. And anyway, we're mostly talking about Fedora here which will have this fixed very soon. See: (That last PR is Fedora CoreOS specific, but similar ones should follow for the other OSTree-based editions.) |
Well, #2125 did help a lot! |
In wstree right now
krb5-libsis a dependency of various things in the base OS.krb5-workstationis an app that uses it - however, it's version locked.This introduces a problem with package layering, since if the compose server picks up a newer version from package mirror A, but the client only has an older version from mirror B, upgrades break. (Or if it's not installed, it can't be).
There are obviously a few solutions to this...likely krb5-workstation should be more flexible, and only introduce a hard requirement on the
-libspackage version if it needs it. Second, we may need to consider a way to retrieve rpm-md data from the same place as the ostree commit, or vice versa. Basically having unified metadata/data management.--
EDIT (2019-09-08): rojig is a much bigger hammer attempting to solve this problem.
The text was updated successfully, but these errors were encountered: