Description of problem: Please drop the gcc dependency (i.e. revert the http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=b6bc0d53767a9750b5291f6d3080c43da5a10a01). So far, I was always happily using my computer without gcc, I hope it will stay like that. Please note that gdb is required by ABRT, which probably makes some sense, hence I have to have gdb on my system. Version-Release number of selected component (if applicable): gdb-7.8.90.20150214-7.fc23
That was in fact a bug, thanks for catching it. It is "Recommends:" now.
This problem has come up again: $ dnf upgrade Last metadata expiration check: 0:04:06 ago on Wed Sep 7 18:06:06 2016. Dependencies resolved. =========================================================================== Package Arch Version Repository Size =========================================================================== Installing: cpp armv7hl 6.2.1-1.fc25 updates-testing 7.1 M gcc armv7hl 6.2.1-1.fc25 updates-testing 15 M gcc-gdb-plugin armv7hl 6.2.1-1.fc25 updates-testing 73 k glibc-devel armv7hl 2.24-3.fc25 fedora 936 k glibc-headers armv7hl 2.24-3.fc25 fedora 482 k isl armv7hl 0.14-5.fc24 fedora 382 k kernel-headers armv7hl 4.8.0-0.rc4.git0.1.fc25 fedora 1.0 M libasan armv7hl 6.2.1-1.fc25 updates-testing 307 k libatomic armv7hl 6.2.1-1.fc25 updates-testing 32 k libmpc armv7hl 1.0.2-5.fc24 fedora 47 k libubsan armv7hl 6.2.1-1.fc25 updates-testing 122 k Upgrading: gdb armv7hl 7.12-0.11.20160904.fc25 updates-testing 2.8 M Transaction Summary =========================================================================== Install 11 Packages Upgrade 1 Package Total download size: 29 M Is this ok [y/N]:
GDB still has: Recommends: gcc-gdb-plugin%{?_isa}
you can use --setopt=install_weak_deps=0 or set it in dnf.conf to not install weak deps.
(In reply to Igor Gnatenko from comment #4) > you can use --setopt=install_weak_deps=0 or set it in dnf.conf to not > install weak deps. oh great, so we now default to installing vast amounts of extra crap, I look forward to the security implications of that.....
(In reply to Peter Robinson from comment #5) > (In reply to Igor Gnatenko from comment #4) > > you can use --setopt=install_weak_deps=0 or set it in dnf.conf to not > > install weak deps. > > oh great, so we now default to installing vast amounts of extra crap, I look > forward to the security implications of that..... It's like this for long time. I don't know what you're referring to about security implications. Actually this is something how langpacks are working. Unfortunately we have to keep yum-compatibility. Personally I would prefer to remove this option.
> I don't know what you're referring to about security implications. It randonly, by default, potentially pulling in vast amounts of random extra crap by default (not just the example above) has security implications....
(In reply to Peter Robinson from comment #7) > > I don't know what you're referring to about security implications. > > It randonly, by default, potentially pulling in vast amounts of random extra > crap by default (not just the example above) has security implications.... There is Suggests tag which in future should be used for such purposes (like examples, etc.). But it should be used only when DNF will get support for choosing packages which to install based on Suggests tag.
> Actually this is something how langpacks are working. Unfortunately we have > to keep yum-compatibility. Personally I would prefer to remove this option. This isn't "yum compatible" as yum has explicit deterministic deps and it wouldn't have pulled that stuff in. This will basically pull in entire compiler stacks for devices/use cases where it was never required/needed. This is still a regression IMO.
> There is Suggests tag which in future should be used for such purposes (like > examples, etc.). But it should be used only when DNF will get support for > choosing packages which to install based on Suggests tag. Is that the same future where we'll have proper verbose debug? If it's the future it should be enabled when that feature lands, not closed a not a bug so it can be swept under the carpet and lost.
(In reply to Peter Robinson from comment #9) > > Actually this is something how langpacks are working. Unfortunately we have > > to keep yum-compatibility. Personally I would prefer to remove this option. > > This isn't "yum compatible" as yum has explicit deterministic deps and it > wouldn't have pulled that stuff in. This will basically pull in entire > compiler stacks for devices/use cases where it was never required/needed. > This is still a regression IMO. Right. It just doesn't support weak deps. Not having feature is better, yes ;)
(In reply to Peter Robinson from comment #10) > > There is Suggests tag which in future should be used for such purposes (like > > examples, etc.). But it should be used only when DNF will get support for > > choosing packages which to install based on Suggests tag. > > Is that the same future where we'll have proper verbose debug? If it's the > future it should be enabled when that feature lands, not closed a not a bug > so it can be swept under the carpet and lost. This is future feature. If you are referring to showing reason why particular package has been pulled in, then it's already implemented and on review.
(In reply to Igor Gnatenko from comment #12) > (In reply to Peter Robinson from comment #10) > > > There is Suggests tag which in future should be used for such purposes (like > > > examples, etc.). But it should be used only when DNF will get support for > > > choosing packages which to install based on Suggests tag. > > > > Is that the same future where we'll have proper verbose debug? If it's the > > future it should be enabled when that feature lands, not closed a not a bug > > so it can be swept under the carpet and lost. > This is future feature. > > If you are referring to showing reason why particular package has been > pulled in, then it's already implemented and on review. Feel free to submit separate request for implementing this.
> > If you are referring to showing reason why particular package has been > > pulled in, then it's already implemented and on review. > Feel free to submit separate request for implementing this. I don't even understand what you mean by this last statement. Please explain?
(In reply to Peter Robinson from comment #7) > It randonly, by default, potentially pulling in vast amounts of random extra > crap by default (not just the example above) Compiler is not "extra crap" for a debugger, GCC is required for GDB, this was already discussed in Bug 1306591, see that Bug 1306591 Comment 8. For example lldb.rpm does Requires (not Recommends) libclang8.so()(64bit). GDB has Recommends as it can fall back on its internal barely working expression evaluator. Plus in some cases debuggers have use cases without any expression evaluation. I do not understand why Comment 13 has reassigned it back to GDB but in such case it is a duplicate now. *** This bug has been marked as a duplicate of bug 1306591 ***
It is a really bad idea on servers and many machines to have a compiler installed. given that gdb is pulled into default installations, also pulling in gcc everywhere is not a good idea. for one it makes the minimal footprint of Fedora bigger and two it makes it trivial for someone that breaks into a machine to compile malicious code, though by then you have other issues. It also has the possibility of encouraging bad behaviour.
(In reply to Dennis Gilmore from comment #16) > It is a really bad idea on servers and many machines to have a compiler > installed. given that gdb is pulled into default installations, I see GDB is required from some common non-development rpms only by abrt-addon-ccpp.rpm and abrt-desktop.rpm. I do not see the reason, maybe ABRT could be repackaged to avoid that given that AFAIK normal bugreports should go through server-side-GDB retrace server.
(In reply to Jan Kratochvil from comment #17) > I see GDB is required from some common non-development rpms only by > abrt-addon-ccpp.rpm and abrt-desktop.rpm. I do not see the reason, maybe > ABRT could be repackaged to avoid that given that AFAIK normal bugreports > should go through server-side-GDB retrace server. ABRT packages pull in gdb because users are allowed to choose between generating backtrace on local machine or on remote machine. This setup ensures that in case of security concerns users are not forced to upload their core files to a remote server. We might be able to tweak ABRT to support only the remote variant of generating backtrace, but I'm not sure it is worth it and I'm not sure users will appreciate such a setup (retrace-server is not a critical service so we sometimes experience some outages /o\) Anyway ABRT must support the local variant of generating backtrace by default. Jan, what about to create a gdb package providing core gdb functionality without the dependency on gcc. We would make ABRT requiring that package instead of full featured gdb?
(In reply to Jakub Filak from comment #18) > ABRT packages pull in gdb because users are allowed to choose between > generating backtrace on local machine or on remote machine. This setup > ensures that in case of security concerns users are not forced to upload > their core files to a remote server. > > We might be able to tweak ABRT to support only the remote variant of > generating backtrace, The GDB dependency could be only optional. Either via Recommends or via Suggests. Then ABRT would show the GDB option disabled if GDB is not installed. Although it is a similar situation as with GDB and its optional expressions evaluation. Making the ABRT->GDB dependency Recommends would not fix the complaint of automatically installed GCC during server installation. > Jan, what about to create a gdb package providing core gdb functionality > without the dependency on gcc. We would make ABRT requiring that package > instead of full featured gdb? If /usr/bin/gdb gets installed then user runs it and the expressions do not work well. No additional GDB-extended package gets installed. GDB could ask user during expression evaluation that gdb-gcc-plugin is not installed and that the user should install it. Similarly to ABRT could ask for GDB installation. I guess this issue should be formalized and submitted to FESCo. For example I am not aware how to do universal package installation - 'dnf install' is not suitable when GDB as a backend of GUI applications.
I have sent it to fedora-devel (instead of FESCo): https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6ZJ3MOQ5IFDCAY2UJ3XQQPRZCG3HB36M/
gdb-7.12-0.16.20160907.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c9d8d46388
gdb-7.12-0.16.20160907.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c9d8d46388
gdb-7.12-0.16.20160907.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1381242 has been marked as a duplicate of this bug. ***