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.

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.

(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.

(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.

(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.

(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.

(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.

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.

(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

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

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

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

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

Fixed as part of DNF 2.0 which will be available at some point soonish.

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