@puiterwijk raised concern that if A is in F26 and packager creates B in F27 which uses new richops (with, without, unless) and later A starts depending on B, the upgradepath is broken because it is performed by old RPM (4.13) which doesn't understand that kind of rich dependencies. What we could do is:
with
without
unless
Personally I prefer #3, but RPM maintainers are against because it would mean that people will ask for more backports. #2 is perfectly fine with me (along with Rust SIG). Even I can speak up for DNF team, I can't make decision to go with #4 just myself. I'm completely unhappy with #1.
Just to note that here we are talking only about new richops -- with, without, unless. All others (if, and, or, else) are completely fine because their support is there since F24 or earlier.
if
and
or
else
If we go way #2, I would write it something like New richops are allowed to use only in rust packages and no other packages can depend on them in runtime.
New richops are allowed to use only in rust packages and no other packages can depend on them in runtime.
Just wanted to note that there are other corner cases, for example:
The maximum supported header size was significantly raised in this release. This cannot be tracked with rpmlib() dependencies as that requires accessing the header, so attempting to access packages with larger than 32MB header will just abruptly fail with ALL older rpm versions.
So if some package in F27 will become such huge that header will be larger than 32MB, update will just fail. Which is unlikely, but such case exists.
Why in the world wouldn't we just use the bootstrap chroot feature in Mock? It was designed for this use-case.
Mock's bootstrap feature ensures that the target RPM and Yum/DNF is used for the chroot setup rather than the host RPM and DNF.
If speed is a concern, then maybe @msuchy could come up with some kind of pre-install image caching or something that could speed up target chroot setup.
@ngompa , how does that help for upgrade user systems? The thing is that upgrade is performed by original RPM.
And I asked about this kind of thing before changing the guidelines....
I can't understand how the second option helps anything. If upgrades are broken, they're broken, right? Permitting just rust packages to be broken seems pointless. (And would probably be something for FESCo to decide in any case.)
Also, does the F25->F27 update case differ? We do support skipping a version, though I'm sure it's far less tested.
Finally, if this does outright break any update scenario (even those we don't support) like F24->F27 or whatever, then it does need to be documented. (Not really an FPC thing at all, but someone should still do it.)
I think you asked generally for rich deps, while this ticket only about new ones.
If upgrades are broken, they're broken, right?
There are no rust packages in F25/F26, so they can't be upgraded..
Doesn't matter, in this area it is same as F26->F27.
So I spoke to DNF team and we are pretty confident that we have solution on DNF side if it becomes blocker in any way.
Metadata Update from @ignatenkobrain: - Issue close_status updated to: invalid - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.