Neal Gompa wrote:
> I consider YUM's behavior of Obsoletes to have been fundamentally
> broken since the beginning of time. This age-old argument between you
> and the DNF developers on Obsoletes needs to die.
I don't see how this can be an "age-old argument", considering that I only
discovered this unhelpful DNF behavior when liberation-fonts hit it. In
fact, I had naĩvely assumed that DNF would be doing the right thing and was
badly surprised by the actual behavior, which sure sounds logical from a SAT
solver perspective (as a mathematician, I understand perfectly why DNF
behaves that way), but from a user perspective, is completely unexpected and
broken.
The complaints I had about the behavior of Obsoletes in DNF in the past were
of different nature, where DNF broke the common idioms to split a package
into several ones. They were partially fixed, but IIRC DNF still does not do
the right thing in all cases.
And then there is the "age-old argument between [me] and the DNF developers"
on the behavior of weak dependencies on package upgrades, which is another
unrelated issue (and one where there is no legacy YUM behavior to refer to,
unlike the Obsoletes issues).
What is common in all cases is that I expect DNF to behave in the way that
both packagers and end users expect, and that allows some packaging patterns
(removing Obsoletes in an update, splitting a package, removing weak
dependencies in an update) to work (the workarounds to make things work with
DNF's existing behavior are always worse in some way, e.g., more side
effects, less universally applicable, more complex, etc.) rather than in the
way that complies naïvely to the definition of a SAT solver.
I do not see what was "fundamentally broken" about the behavior of Obsoletes
in YUM. If foo-1 Obsoletes: bar and foo-2 no longer Obsoletes:bar, and if
bar is available, my expectation both as a packager and as an end user is
that DNF upgrades foo from foo-1 to foo-2, and if something Requires: bar,
installs bar (otherwise, bar should not get installed by default). In
implementation terms, this means that Obsoletes from outdated versions of a
package should not get processed, i.e.:
∀n-evr∊Packages: if ∃n-evr'∊Packages:evr'>evr, discard Obsoletes from n-evr
I don't know whether YUM got this right by design or (as the DNF developers
claim) by accident (because it discarded the old EVRs completely, also not
considering downgrades to solve problems), but either way, this can be done
right by design in DNF/libsolv.
I think the fundamental disagreement between me and the DNF and libsolv
developers is that I believe that a SAT solver needs some additional rules
like the above to be usable in practice, whereas the DNF and especially
libsolv developers seem to believe in an as pure SAT solver as possible
(even though there are already some special-case rules implemented in some
places, they are just not sufficient to cover all corner cases where user
expectations differ from the raw SAT problem).
> It's also important to note that papering over stupid is only required
> because Fedora doesn't allow by policy to clean up stupid in the
> development release. That's why we have asinine things like "Epoch:
> 12" in dhcp, among many other things.
This is not the issue here. The liberation-fonts Obsoletes issue was purely
within a release (both F29 and F30 were affected), where the GA version has
a bad Obsoletes and there is no way for an update to get it out of DNF's
view because DNF always sees the old GA version too and takes its bad
Obsoletes into account. So this is NOT about the upgrade path from one
release to another.
> Much of this is around the fetish that "dnf upgrade" is supposed to
> technically work to move to the next release by policy, even though it
> never worked for various reasons. This is why the system-upgrade
> plugin switched to the distro-sync/dist-upgrade method.
Well, I think that keeping an upgrade path from one release to the next does
actually make sense. And when it comes to Obsoletes (i.e., package
replacements, merges, or splits), distro-sync will also not help you, it can
only downgrade the EVR of a package with unchanged name. (So, in particular,
I also do not see how your proposed policy change would have fixed the issue
in this thread.)
What I find more problematic is the requirement of an upgrade path without
distro-sync from Rawhide to Rawhide, i.e., that broken builds can no longer
be simply untagged if they already went out in a compose, because we require
the fix to have a higher EVR. This leads to very avoidable Epoch bumps (with
which we then get stuck forever due to the policy you are unhappy with). I
see the point of upgrade paths from release to release or even from release
to Rawhide, but from Rawhide to Rawhide, just no. (But that is again an
unrelated issue that I already brought up in the relevant threads.)
> DNF does have some broken behaviors, but this isn't one of them.
Sorry, I still think it is.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
