Hi! On Wed, 2024-01-03 at 15:04:01 -0700, Sam Hartman wrote: > >>>>> "Guillem" == Guillem Jover <guil...@debian.org> writes: > Guillem> At least the dpkg behavior seems entirely > Guillem> correct to me and required for safe upgrades ( > > Can you help me understand the sentence above? > Where is the case where this behavior is needed for safe upgrades? > (I am asking out of curiosity; I'm guessing it's some corner case with > essential packages, but I would like to understand.)
I should probably have qualified that statement, where safe upgrades is restricted to the specific scenarios at hand. In any case, I don't think this is specific to essential packages, this seems more general. But of course the effects of not supporting such safe upgrades for essential packages would be potentially more severe (although an essential package can never be a conflictor as dpkg would refuse to remove it). In essence this involves a cyclic restriction where a set of packages are stating they cannot be unpacked at the same time, but later versions might be. There are several subcases for this depending on the strength of the dependencies from each side, whether these are versioned, and also whether the package manager front-end or the user decides whether to fully evict a conflictor or wants to upgrade to a latest version that can co-exist. What the current behavior permits is to safely intertwine an unpack, a conflictors files transfer and its removal in the same step, so that the front-end or the user does not need to apply --force-* options to forcibly remove the conflictor while breaking the dependency system for an undetermined amount of time, to be able to proceed with such upgrade. I don't see any other way around this kind of upgrade that does not break the dependency system besides the current behavior (if someone does, I'm happy to hear it). Of course there's always the option to prohibit those kinds of relationships, which means the behavior never is brought up, and there's no need either to be concerned about whether it needs to be supported or not. But that seems overly restrictive, because once or if you need to express that kind of relationship, then that path would be closed. All this being said, when Helmut brought this up, I noticed that dpkg is expecting to be hand held by giving to it the proper order for these operations (as front-ends do), or it will either fail to upgrade depending on the scenario, or unnecessarily use the conflictor eviction behavior, which are not ideal (but do not break the dependency system). I've got some test cases (Conflicts vs Breaks, Conflicts vs Conflicts), which I should expand to add addition restrictions in the form of Depends and Pre-Depends, unversioned relationships and similar, after which I'll look into improving the way dpkg schedules its processing queue in these cases so that it is a bit smarter about them and does not fail so easily or uses this behavior unnecessarily when there's a path forward at hand. But this seems besides the point of the conflictor eviction behavior. Thanks, Guillem
