On Sat, Jan 28, 2023 at 1:23 PM Gordon Messmer <gordon.mess...@gmail.com> wrote: > > On 2023-01-28 00:14, Bruno Wolff III wrote: > > If there is a problem with not uodating dependencies when you do an > > install or an update on selected packages, the packages dependencies > > are not properly defined. > > > By definition, yes. But rpm auto-detects dependencies, and rpm doesn't > do symbol-level dependency detection, so it doesn't capture > minor-version dependency creep. In order for rpm to do this, you'd > probably have to throw out the current implementation of dependency > resolution that provides "libfoo.so.2()(64bit)" and instead provide a > dependency like "(foo-libs >= 2.4 with foo-libs < 3)", at least for the > cases where libraries do not provide versioned symbols -- which I > believe includes the vast majority of them. (You'd also need to forbid > restructuring packages within a stable release.)
The RPM build process tries to do so, but it can't possibly outsmart the morass of dependencies that "modularity" tends to create. It's why so many have given up on modularity since its introduction in Fedora, and one of the reasons I have trouble getting approval to do RHEL 8 and RHEL 9 updates. The various sets of "modularity" components are not tested against all the other versions of related packages: I'm running into this headlong with ansible collections and the morass of dependency chains weaving into and out of modularity deployed coponents, myself. The "modular" channels are almost invariably incomplete and require additional RPM builds to satisfy "test" or "doc" building steps from the same base software package. Modularity and its inevitable build-time and deployment inconsistencies have consistently hindered dependency management. > > I think the case where you don't want to keep the full system up to > > date, but a selective update or install causes problems as well is > > pretty rare. I think it might be reasonable to have an option that > > requests doing a recursive update. I would consider this to be a low > > priority feature request that has to compete with all of the other > > work being done on dnf, rather than a bug. I don't work on dnf and the > > people that do might feel differently. > > > Yeah, I agree, it's not super high priority. But it's also not really > well understood among the community that partial updates (such as `dnf > update --security`) and package installation without a contemporaneous > update are unreliable. Yeah. It's hard to predict exactly when it will break, but it *does* break. Unfortunately, so do fork list upgrades, such as using a base OS image that is three years old and then doing "dnf -y update" on it. It's very difficult to predict which update will break what, but updating 700 packages at once as I just saw on a base OS image of RHEL 8. It's one reason Fedora's frequent releases are useful: they provide a much fresher, smoke tested baseline image to apply changes to, rather than relying on upgrades in places. > I can work on some of those changes to documentation and to rpm or dnf, > but I'd like input from the developer community before starting. (And > at some point I think that Fedora, the org, should probably consider > whether `dnf update --security` is broken and unreliable.) It's popular. I'm remembering when the "dnf update -y --security" broke curl, because either "curl-libs" or "crypto-policies" was not listed in those updates, and hilarity ensued. It's why I try to schedule regular "dnf -y update" operations, and updating my base OS images to match. It can get a bit awkward when the base OS images at your favorite cloud vendor fall increasingly out of date over time. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
