Bug 1306591 - when weak_install_weak_deps==False don't show weak dependencies in "Skipping packages with conflicts" section
when weak_install_weak_deps==False don't show weak dependencies in "Skipping ...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Honza Silhan
Fedora Extras Quality Assurance
: Reopened
: 1312919 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-11 06:51 EST by Ralf Corsepius
Modified: 2016-10-04 15:14 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-21 10:31:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2016-02-11 06:51:35 EST
Description of problem:
Todays update to gdb (gdb-7.10.50.20160131-51.fc24) pulls in several *devel packages.

Version-Release number of selected component (if applicable):
gdb-7.10.50.20160131-51.fc24

How reproducible:
Always

Steps to Reproduce:
1. Install gdb 
2. Watch the deps.

Actual results:
# dnf update gdb
....
Installing:
 gcc              i686 6.0.0-0.10.fc24  rawhide                    18 M
 gcc-gdb-plugin   i686 6.0.0-0.10.fc24  rawhide                    69 k
 glibc-devel      i686 2.22.90-33.fc24  rawhide                   930 k
 glibc-headers    i686 2.22.90-33.fc24  rawhide                   497 k
 kernel-headers   i686                   4.5.0-0.rc3.git1.1.fc24                 rawhide                   1.0 M
Upgrading:
 gdb              i686 7.10.50.20160131-51.fc24  rawhide                   3.4 M
...

Additional info:
I don't know the cause for this dependency bloat, but it is incomprehensible to me why a "mere program" (such as gdb) would want to pull in devel-packages comprising headers and a compiler.
Comment 1 Jan Kratochvil 2016-02-11 07:13:08 EST
It is because gdb.spec contains:
Recommends: gcc-gdb-plugin%{?_isa}

(In reply to Ralf Corsepius from comment #0)
> I don't know the cause for this dependency bloat, but it is incomprehensible
> to me why a "mere program" (such as gdb) would want to pull in
> devel-packages comprising headers and a compiler.

It is because GDB can compile C code and thus it is useful to have the basic devel packages:

https://sourceware.org/gdb/onlinedocs/gdb/Compiling-and-Injecting-Code.html#Compiling-and-Injecting-Code

$ gdb -batch true -ex start -ex 'compile printf("result=%d\n",1+2);'
[...]
result=3

One may argue whether it should be "Recommends" or "Suggests", for plain C it possibly may be just "Suggests" but given soon GDB will gain the 'compile' support even for C++ and in C++ the 'compile' feature is mostly required for meaningful debugging GDB would soon switch to "Recommends" anyway.
Comment 2 Jan Kratochvil 2016-02-11 07:26:02 EST
And to resolve the problem for your special installation purposes:
# dnf --setopt install_weak_deps=false install gdb

But for some reason I cannot test it as 'dnf install gdb' does not automatically install 'gcc-gdb-plugin' for me on my two hosts.  But I do not have clean enough test host to bugreport that to dnf.
Comment 3 Ralf Corsepius 2016-02-11 08:12:35 EST
(In reply to Jan Kratochvil from comment #2)
> And to resolve the problem for your special installation purposes:
> # dnf --setopt install_weak_deps=false install gdb

Jesus! I really hate to rant, but this doesn't leave me no other choice.
To put it politely: RH, the Fedora leadership and the dnf guys are suffering from blindness to the company's failings.

> But for some reason I cannot test it as 'dnf install gdb' does not
> automatically install 'gcc-gdb-plugin' for me on my two hosts.
The system I am using, is a "grown" real world rawhide installation on an old i686-machine, I am using for experiments.

>  But I do not
> have clean enough test host to bugreport that to dnf.
I could send you the list of packages I have installed on this machine ;) Basically, it's an xfce desktop with a bit of Gnome underneath. Before today, it had no devel packages installed, but it had gdb installed. Then came this update and pulled-in this bloat.
Comment 4 Jan Kratochvil 2016-02-11 08:24:36 EST
(In reply to Ralf Corsepius from comment #3)
> To put it politely: RH, the Fedora leadership and the dnf guys are suffering
> from blindness to the company's failings.

These are not my decision, personally I would prefer a switch to LLDB.

> > But I do not have clean enough test host to bugreport that to dnf.
> I could send you the list of packages I have installed on this machine ;)

To make it clear - I find your Comment #0 as a valid behavior (for 'install', not for 'update').  Only my system for whatever reason behaves wrongly (=not installing gcc-gdb-plugin) but that is offtopic here.

> Before today, it had no devel packages installed, but it had gdb installed.
> Then came this update and pulled-in this bloat.

An update should not bring in new packages I think but that is all up to DNF, not GDB.  Therefore reassign+reopen it for DNF if you think the 'update' does not behave correctly.
Comment 5 Ralf Corsepius 2016-02-11 09:11:38 EST
(In reply to Jan Kratochvil from comment #4)
> (In reply to Ralf Corsepius from comment #3)
> > To put it politely: RH, the Fedora leadership and the dnf guys are suffering
> > from blindness to the company's failings.
> 
> These are not my decision, personally I would prefer a switch to LLDB.
The more severe problem behind this: Nobody wants to take responsibility.
Everybody pretends "everything was in splendid shape", everybody cheats.


> > > But I do not have clean enough test host to bugreport that to dnf.
> > I could send you the list of packages I have installed on this machine ;)
> 
> To make it clear - I find your Comment #0 as a valid behavior (for
> 'install', not for 'update'). 
Well, I consider adding devel packages to a mere desktop as part of an update to be "inacceptable misbehavior".

Apparently yet another situation, the promoters of weak deps and dnf did not consider.

> An update should not bring in new packages I think but that is all up to
> DNF, not GDB.  Therefore reassign+reopen it for DNF if you think the
> 'update' does not behave correctly.
I had to learn, the dnf guys are blind to their failures. Likely they are to inexperienced to comprehend where and why are failing.

That said, I've learnt reporting bugs against dnf is a waste of time.

Finally, trying your proposal (Now with gdb removed):

# dnf --setopt install_weak_deps=false install gdb
..
 gdb              i686   7.10.50.20160131-51.fc24     rawhide   3.4 M
 libipt           i686   1.4.4-2.fc24                 rawhide    44 k
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 gcc              i686   6.0.0-0.10.fc24              rawhide    18 M
 gcc-gdb-plugin   i686   6.0.0-0.10.fc24              rawhide    69 k
 glibc-devel      i686   2.22.90-33.fc24              rawhide   930 k
 glibc-headers    i686   2.22.90-33.fc24              rawhide   497 k
 kernel-headers   i686   4.5.0-0.rc3.git1.1.fc24      rawhide   1.0 M
 libmpx           i686   6.0.0-0.10.fc24              rawhide    22 k
...

The same level experience with dnf, as always: An absurd message about conflicts. Obviously, dnf is not ready for weak deps.
Comment 6 Jan Kratochvil 2016-02-11 09:36:54 EST
(In reply to Ralf Corsepius from comment #5)
> Well, I consider adding devel packages to a mere desktop

If it is a "mere desktop" why do you need GDB there?  For a good enough debugging you really need even a compiler, LLDB uses LLVM for that.


For the '# dnf --setopt install_weak_deps=false install gdb' part reassigning to DNF.
Comment 7 Ralf Corsepius 2016-02-12 00:03:06 EST
(In reply to Jan Kratochvil from comment #6)
> (In reply to Ralf Corsepius from comment #5)
> > Well, I consider adding devel packages to a mere desktop
> 
> If it is a "mere desktop" why do you need GDB there?
E.g. to examine/inspect core dumps.

In general another use case would be using gdb to control remote debugging on remote targets (over a serial wire) and using gdb as a simulator.

>  For a good enough
> debugging you really need even a compiler, LLDB uses LLVM for that.
I do not agree with this. A debugger which requires a compiler is flawed design.
Comment 8 Gary Benson 2016-02-12 04:44:42 EST
The debugger requires a compiler in order to evaluate commands such as 'print a.b->c' or 'call puts("hello world")'.  We're not so much adding a compiler as replacing one with another.
Comment 9 Honza Silhan 2016-02-18 07:54:22 EST
(In reply to Ralf Corsepius from comment #5)
> # dnf --setopt install_weak_deps=false install gdb
> ..
>  gdb              i686   7.10.50.20160131-51.fc24     rawhide   3.4 M
>  libipt           i686   1.4.4-2.fc24                 rawhide    44 k
> Skipping packages with conflicts:
> (add '--best --allowerasing' to command line to force their upgrade):
>  gcc              i686   6.0.0-0.10.fc24              rawhide    18 M
>  gcc-gdb-plugin   i686   6.0.0-0.10.fc24              rawhide    69 k
>  glibc-devel      i686   2.22.90-33.fc24              rawhide   930 k
>  glibc-headers    i686   2.22.90-33.fc24              rawhide   497 k
>  kernel-headers   i686   4.5.0-0.rc3.git1.1.fc24      rawhide   1.0 M
>  libmpx           i686   6.0.0-0.10.fc24              rawhide    22 k
> ...
> 
> The same level experience with dnf, as always: An absurd message about
> conflicts. Obviously, dnf is not ready for weak deps.

I don't know why completely different bug report ended on DNF component, but ok, let's track issue in the comment above in this BZ.

The packages which were pulled in as a weak dependencies were shown in "Skipping packages with conflicts" section -> UX DNF bug.

PR: https://github.com/rpm-software-management/dnf/pull/443
Comment 10 Jan Kurik 2016-02-24 09:29:36 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 11 Jan Kratochvil 2016-02-29 09:30:45 EST
*** Bug 1312919 has been marked as a duplicate of this bug. ***
Comment 12 Mike McCune 2016-03-28 18:49:28 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 13 Peter Robinson 2016-05-11 08:55:50 EDT
This seems to have regressed again recently.

# dnf upgrade --refresh
Fedora 24 - aarch64                                                                                                                            1.9 MB/s |  41 MB     00:21    
Last metadata expiration check: 0:00:47 ago on Wed May 11 12:50:05 2016.
Dependencies resolved.
========================================================================
 Package         Arch       Version          Repository   Size
========================================================================
Installing:
 binutils        aarch64    2.26-18.fc24     fedora       5.5 M
 cpp             aarch64    6.0.0-0.20.fc24  fedora       7.5 M
 gcc             aarch64    6.0.0-0.20.fc24  fedora        16 M
 gcc-gdb-plugin  aarch64    6.0.0-0.20.fc24  fedora        73 k
 glibc-devel     aarch64    2.23.1-5.fc24    fedora       931 k
 isl             aarch64    0.14-5.fc24      fedora       434 k
 libasan         aarch64    6.0.0-0.20.fc24  fedora       304 k
 libatomic       aarch64    6.0.0-0.20.fc24  fedora        25 k
 libmpc          aarch64    1.0.2-5.fc24     fedora        54 k
 libubsan        aarch64    6.0.0-0.20.fc24  fedora       120 k
 mpfr            aarch64    3.1.4-1.fc24     fedora       204 k
Upgrading:
 gdb             aarch64    7.11-66.fc24     fedora       2.7 M

Transaction Summary
========================================================================
Install  11 Packages
Upgrade   1 Package

Total download size: 34 M
Is this ok [y/N]: 


Installed dnf stack:
dnf-1.1.8-1.fc24.noarch
dnf-conf-1.1.8-1.fc24.noarch
dnf-langpacks-0.15.1-4.fc24.noarch
dnf-langpacks-conf-0.15.1-4.fc24.noarch
dnf-plugins-core-0.1.20-1.fc24.noarch
dnf-yum-1.1.8-1.fc24.noarch
python3-dnf-1.1.8-1.fc24.noarch
python3-dnf-langpacks-0.15.1-4.fc24.noarch
python3-dnf-plugins-core-0.1.20-1.fc24.noarch
hawkey-0.6.3-2.fc24.aarch64
python3-hawkey-0.6.3-2.fc24.aarch64
python3-librepo-1.7.18-2.fc24.aarch64
librepo-1.7.18-2.fc24.aarch64
Comment 14 Igor Gnatenko 2016-07-21 10:31:50 EDT
Fixed as part of DNF 2.0 which will be available at some point soonish.
Comment 15 Jan Kratochvil 2016-09-08 08:32:55 EDT
*** Bug 1195005 has been marked as a duplicate of this bug. ***

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