Re: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux