Dne 27. 06. 19 v 23:56 Zbigniew Jędrzejewski-Szmek napsal(a): > On Thu, Jun 27, 2019 at 10:37:28AM -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/DNF_Default_Best > I wanted to update today, and I got the following report: > $ sudo dnf upgrade --best > Last metadata expiration check: 0:00:18 ago on Thu 27 Jun 2019 10:45:00 PM > CEST. > Error: > Problem: package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libnetlib.so.1.14()(64bit), but none of the providers can be installed > - package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libv3p_netlib.so.1.14()(64bit), but none of the providers can be installed > - package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libvcl.so.1.14()(64bit), but none of the providers can be installed > - package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libvnl.so.1.14()(64bit), but none of the providers can be installed > - package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libvnl_algo.so.1.14()(64bit), but none of the providers can be installed > - cannot install both vxl-2.0.2-4.fc30.x86_64 and vxl-1.17.0-30.fc30.x86_64 > - cannot install both vxl-1.17.0-30.fc30.x86_64 and vxl-2.0.2-4.fc30.x86_64 > - cannot install the best update candidate for package > vxl-1.17.0-30.fc30.x86_64 > - cannot install the best update candidate for package > InsightToolkit-4.9.1-9.fc29.x86_64 > (try to add '--allowerasing' to command line to replace conflicting packages > or '--skip-broken' to skip uninstallable packages) > > The problem with this is that it's not possible to figure out what who is too > blame. > Specifically: > 1. How am I to know that vxl is related to libnetlib.so.1.14()(64bit) and > the other virtual provides? > > 2. >> - cannot install the best update candidate for package >> vxl-1.17.0-30.fc30.x86_64 >> - cannot install the best update candidate for package >> InsightToolkit-4.9.1-9.fc29.x86_64 > I see that vxl-1.17 and vxl-2.0.2 are mentioned. 1.17 is the older version. > So this message talks about old vxl version, so I assume it also talks about > old InsightToolkit version. But all logs above that only talk about one > version > of InsightToolkit. Why would I care about requirements of the old version, > when > about to upgrade to new version? What is even the new InsightToolkit version > dnf is trying to upgrade to? > > 3. >> - cannot install both vxl-2.0.2-4.fc30.x86_64 and vxl-1.17.0-30.fc30.x86_64 >> - cannot install both vxl-1.17.0-30.fc30.x86_64 and vxl-2.0.2-4.fc30.x86_64 > The second line is noise, already reported previously, but I can't find the > bug > now. > > So even in simple case with two packages, I'd need to do repoquery spelunking > to figure out what is going on. If dnf could tell me something like... > > Problem: package InsightToolkit-4.9.1-9.fc29.x86_64 requires > libnetlib.so.1.14()(64bit), libv3p_netlib.so.1.14()(64bit), > libvcl.so.1.14()(64bit), libvnl.so.1.14()(64bit), > libvnl_algo.so.1.14()(64bit), currently provided by vxl-1.17.0. > - There is no upgrade candidate for InsightToolkit. > - Best upgrade candidate vxl-2.0.2-4.fc30.x86_64 does have those Provides. > → cannot install both vxl-2.0.2-4.fc30.x86_64 and > vxl-1.17.0-30.fc30.x86_64 because vxl is not an installonly package. > → cannot install the best update candidate for package vxl > > i.e. group relevant Provides that "connect" two package into one list instead > of repeating the whole set of messages every time, > don't talk about upgrade candidates that don't actually exist, > mention the connection between Provides and package names, > omit evra when not required, > provide more explanations in general, > > then I'd see this change in a more positive light. I think the output > right now is just noise for most users. > > The premise that bug reports from users will help us catch such cases > — I don't see this as true. We *already know* that InsightToolkit has a > problem, > there's a FTBFS bug for it somewhere. > > The idea of "fault tolerant systems" is that the system mostly > continues to work in face of small failures in components. The distro > is a big system with thousands of interacting components, and *some* > simply must fail occasionally. The proposal is to make the system > fault-intolerant to notice errors earlier. That just seems wrong. > Returning to the example, why can't dnf print in red letters > at the end of the transaction log: > > Upgrade of vxl-1.17.0-30.fc30.x86_64 to vxl-2.0.2-4.fc30.x86_64 was held > back because of dependency issues. > > Users would see that too.
Yep, this is problem. I opened DNF tickets requesting improvement of the messages, but apparently unsuccessfully :( Vít > > Zbyszek > _______________________________________________ > 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 _______________________________________________ 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
