Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1303978 - releng needs to get verbose depsolving info
Summary: releng needs to get verbose depsolving info
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 27
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1396844 (view as bug list)
Depends On:
Blocks: rel-eng-dnf
TreeView+ depends on / blocked
 
Reported: 2016-02-02 15:33 UTC by Dennis Gilmore
Modified: 2018-09-24 18:48 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-24 18:48:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1427365 0 medium CLOSED DNF (and thus anaconda, livemedia-creator...) skips packages that are missing or cannot be installed due to conflicts or... 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1461539 0 unspecified CLOSED Provide broken/missing group package behaviour identical to yum's (accept missing packages, fail on broken packages) 2022-09-02 20:22:13 UTC

Internal Links: 1427365 1461539

Description Dennis Gilmore 2016-02-02 15:33:52 UTC
Description of problem:

When running compose taska and when making buildroots we need to be able to debug dependency issues from the log files. We need to have a flag to turn on vebose logging of depsolving.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Honza Silhan 2016-02-03 13:02:46 UTC

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

Comment 2 Dennis Gilmore 2016-10-21 13:49:59 UTC
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.

Comment 3 Igor Gnatenko 2016-10-21 13:51:26 UTC
(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?

Comment 4 Dennis Gilmore 2016-10-21 16:00:37 UTC
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.

Comment 5 Michael Mráka 2016-10-24 11:15:32 UTC
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?

Comment 6 Dennis Gilmore 2016-10-27 22:15:54 UTC
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.

Comment 7 Dennis Gilmore 2016-10-27 22:17:34 UTC
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.

Comment 8 Honza Silhan 2016-10-31 12:06:30 UTC
we can reconstruct the dependency tree and output that.

Comment 9 Dennis Gilmore 2016-11-07 16:02:20 UTC
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.

Comment 10 Igor Gnatenko 2016-11-21 09:03:36 UTC
*** Bug 1396844 has been marked as a duplicate of this bug. ***

Comment 11 Fedora End Of Life 2017-02-28 09:53:39 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 12 Jaroslav Mracek 2017-04-11 18:30:44 UTC
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?

Comment 13 Dennis Gilmore 2017-04-11 23:57:06 UTC
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.

Comment 14 Panu Matilainen 2017-04-12 05:21:42 UTC
(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.

Comment 15 Dennis Gilmore 2017-04-18 19:11:00 UTC
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

Comment 16 Jaroslav Mracek 2017-04-24 15:33:12 UTC
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.

Comment 17 Jaroslav Mracek 2017-04-24 16:02:19 UTC
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.

Comment 18 Jaroslav Mracek 2017-04-24 16:08:51 UTC
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.

Comment 19 Dennis Gilmore 2017-06-06 20:30:40 UTC
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.

Comment 20 Jan Kurik 2017-08-15 08:34:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 21 Jaroslav Mracek 2018-09-24 18:48:43 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.