Bug 1303978

*** This bug has been marked as a duplicate of bug 1148627 ***

This is not a duplicate, as we need to have full depsolving displayed in releng as opposed to just having enough depsolving to figure out what is going on.  There should be some flag we can use to make dnf loud about what is going on, Just as yum was.

(In reply to Dennis Gilmore from comment #2)
> This is not a duplicate, as we need to have full depsolving displayed in
> releng as opposed to just having enough depsolving to figure out what is
> going on.  There should be some flag we can use to make dnf loud about what
> is going on, Just as yum was.

Do you use dnf as subprocess or you use API?

both, in koji/mock it is used by the cli, other tools are using the yum api and can not be ported until we get suitable output.

If there's dependency issue and transaction fails then (failed) dependency chain is reported.

Why do you need full depsolving displayed in success case? What's the use case / what do you use it for?

full depsolving is needed because there are cases where you get more packages than expected and some additional functionality gets enabled. There are cases where you need to figure out why something was pulled into a buildroot. it is not only failures that cause people to analyze why something was or was not pulled into a buildroot.

https://pagure.io/releng/blob/master/f/scripts/critpath.py for instance, we want to know what packages cause another package to get pulled into being critical path.

we can reconstruct the dependency tree and output that.

another case we hit today, for some reason systemd-udev stopped being pulled into the livemedia buildroot in rawhide. we have no idea why that is, the transaction completes but does not have all the expected packages. As a result we have to do a lot of digging to figure it out, with proper verbose logs we could see why it was previously pulled in to the chroot and narrow down where to look for changes.

*** Bug 1396844 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

I create huge refactor of problems report https://github.com/rpm-software-management/dnf/pull/782, but not sure if the patch fulfill the request in this bug report. Please can you look at PR and provide a feedback?

It does not look even close to what we are requesting. we want all package depsolving from the start of the transaction to be printed. it serves many purposes. from figuring out why something was chosen to being able to determine differences that cause unexpected or to confirm expected behaviour. we need to know depsolving issue when the transaction is successful  and not just in cases of errors.

(In reply to Honza Silhan from comment #8)
> we can reconstruct the dependency tree and output that.

That, with missing and looped dependencies marked specially, sounds like a fine plan to me.

we hit a failure today that the output is lacking in any detail as to whats going on.

DEBUG util.py:435:  Unable to create appliance : Failed to build transaction : package webkitgtk4-2.16.1-2.fc26.armv7hl requires libenchant.so.1, but none of the providers can be installed
DEBUG util.py:435:    - package emacs-1:25.2-0.1.rc2.fc26.armv7hl requires libwebkit2gtk-4.0.so.37, but none of the providers can be installed
DEBUG util.py:435:    - package enchant-1:1.6.0-16.fc26.armv7hl requires libhunspell-1.5.so.0, but none of the providers can be installed
DEBUG util.py:435:    - conflicting requests
DEBUG util.py:435:    - nothing provides hunspell-en-US needed by hunspell-1.5.4-2.fc26.armv7hl

all the packages talked about exist and are available. full debugging is needed

Please can you provide additional information for last Comment 15 like what was the last issue in this operation and from which operation the error appears like (install or upgrade)? Thanks a lot. And probably I will have additional request or question because I am going to try to solve your request.

From Comment 15 I guess that hunspell-en-US provide was not present in transaction. The rest is simple consequence dependency problems in dependency tree.

Dennis please can you provide expected result how would you prefer format requested verbose output in several cases - problem, missing package in transaction, transaction without problem or something else. This is very important to delivery what you requested. Thanks a lot.

Sorry I had missed the request for info. From memory there was no other detail. it was creating an arm disk image and that was the full output after loading the repos. the logs no longer exist to provide anything extra. 

hunspell-en-US was present in the repo and metadata, I am assuming that it was not installable due to some broken dep, it was just never shown anywhere.

What we would like is to have the full depsolving from the start. so that we can see why packages are included or not included. For realease engineer purposes we need to have the full depsolving output for the entire transaction all the time. sometimes the transaction completes and does not give the expected desired outcome, we need to be able to figure out why that happened. othertimes things are broken we need to know why exactly. the sample output does not provide enough information to determine the cause of the problem. We need to know the full depsolving when things are good so that when things go wrong we can compare and figure out what exactly changed to make them go wrong.

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

I think that dnf-3.6.0 with new group handling will provide sufficien amount of data. Please you you think that there is an issue, please don't hesitate to reopen bug report with detailed information.