Description of problem: Reasonably basic install of Fedora 9 Pre-Release. Don't have any wireless devices on the server, so I try to "yum remove wireless-tools". The action would result in 14 package removals - most of which I do NOT want removed. Version-Release number of selected component (if applicable): 29-2.fc9.i386 How reproducible: N/A - every time I try to remove it. Steps to Reproduce: 1. Basic Fedora installation on a server 2. yum remove wireless-tools Actual results: Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: wireless-tools i386 1:29-2.fc9 installed 187 k Removing for dependencies: firstboot i386 1.96-1.fc9 installed 610 k policycoreutils-gui i386 2.0.46-5.fc9 installed 598 k rhpl i386 0.215-2 installed 795 k rhpxl i386 1.9-1.fc9 installed 309 k system-config-date noarch 1.9.30-1.fc9 installed 3.7 M system-config-display noarch 1.0.51-9.fc9 installed 678 k system-config-firewall noarch 1.2.7-1.fc9 installed 1.7 M system-config-firewall-tui noarch 1.2.7-1.fc9 installed 1.5 M system-config-keyboard noarch 1.2.15-2.fc9 installed 189 k system-config-network noarch 1.5.6-1.fc9 installed 1.8 M system-config-network-tui noarch 1.5.6-1.fc9 installed 4.6 M system-config-nfs noarch 1.3.40-1.fc9 installed 1.9 M system-config-users noarch 1.2.79-1.fc9 installed 2.8 M Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 14 Package(s) Is this ok [y/N]: n Expected results: Expect to be able to remove wireless-tools without disturbing packages that do NOT require wireless-tools to run. Additional info: Think I've raised this bug before. I've certainly raised it against RHEL5 as it's a security issue in the Bank where I work. Although it's not a security issue for me at home, I'd rather not install packages that I won't be using in any way shape or form. Whichever package depends on wireless-tools needs to be amended to remove the dependency, or some package splitting need to be done to ensure that system-config-users (or some other basic packages) don't get removed.
wireless-tools ships libiw, which a lot of stuff links to. Perhaps the better solution here is to split off a -libs sub-package with the library and keep the binary tools in the main package so that you can remove the binaries instead. Bill? Thoughts?
You could split out the libs if you wanted to, I suppose. That being said, there's no way this is a security issue.
I'm OK with it not being a security risk, but try telling that to the triple-A bank I work for. I'm currently wading through the RHEL5 installs we do writing up justifications and risk assesments for all installed packages. Wireless- tools just cries out as being unnecessary in a datacentre with no wireless devices, yet removing it is impossible. Fedora users in general perhaps won't find issue with this, but it still smacks as being something that shouldn't happen. Perhaps just a bit of tangling in the dependency tree. But it would still be better sorted out I think.
I find it odd that they would take offense to wireless-tools but would want: * system-config* which runs X applications as root (SECURITY RISK) * rh*pl which are the libraries used by the former * firstboot which is only run the first time the system is booted
Sorry if there's any confusion. The package list above is quite clearly for Fedora 9 and is from one of my home machines. This is a Fedora 9 issue - I used the example of my employer purely to illustrate the different views people have on what constitutes a security risk. The issue for my employer is being chased through an RHN Service Request, but should appear in bugzilla soon. It will be filed as a RHEL 5 bug. I just don't we any reason for forcing the installation of wireless-tools on every installation. I only have wireless available on my laptop, but it is installed on all 4 of my machines. It shouldn't be a requirement on any of those systems as they all have Gigabit RJ45 only.
And what if a user were to purchase a PCI or USB wireless device? And plugged it in only to find out, OH NOES! it doesn't work. Other OSes would simply just work. See also: rpm -ql kernel | grep drivers
That's all very well for other OS's. The plain fact is that basic packages like firstboot, policycoreutils-gui, system-config-date, system-config-users etc should NOT depend on wireless-tools. Feel free to put wireless-tools in the standard base installation, but I should be allowed to remove it if I want. This takes care of the "OH NOES!" user situation that you describe above as the stupid user will have taken the base install and will HAVE wireless-tools installed. I, however, will have decided to remove wireless-tools as it means nothing to me.
So, um, file bugs on those apps to not depend on it?
Though really, it's that rhpl depends on it. And system-config* depends on rhpl.
Or split the wireless-tools package as was suggested by Dan Williams and Bill Nottingham?
But you still won't be able to remove the wireless support from the distro if other programs still require it.
*IF* other programs require it. This is filed as a bug report because *currently* wireless-tools is required by rhpl - as you pointed out. Now either rhpl really does require something that it in wireless-tools or the rhpl developers just decided to make wireless-tools a dependency for the hell of it. It's filed here as a wireless-tools bug because there's a case for splitting up wireless-tools into components. If it turns out that wireless-tools is completely faultless in this scenario, then I will change the component for this bug to rhpl. As it stands, you seem to be resisting any investigation of wireless-tools based on a "what if" and a "this has nothing to do with wireless-tools". There's an open bug https://bugzilla.redhat.com/show_bug.cgi?id=351101 about NetworkManager being a requirement of too many irrelevant packages. This one seems to be similar. Trying to convince people that it's OK and everything is nice is not going to work. If I have no wireless devices, I should NOT have to install wireless-tools as a dependency of other packages.
So here's the crux of the matter: you're essentially objecting to having a package with wireless in it's name installed on your computer. There is no change that can be made to wireless-tools that can let you do that without removing all the packages you have already objected to removing because of the rhpl dependency. If we make the proposed fix, you will no longer need wireless-tools but will need wireless-libs in its place and that is not what you want, either, AFAICT. What you really want is for rhpl to be split so that apps that don't really need iwlib (system-config-date etc) don't have to have it installed. Even then, you will still be out of luck because system-config-network (which you say you do not want to remove) will require the wireless bits, however here splitting out wireless-tools into wireless-libs will let you remove the tools applications such as iwconfig, iwscan, etc. but you will still be required to have wireless-libs installed if you do not wish to remove system-config-network.
No - there are two ends to this stick and one of us is definitely wrestling with the wrong end. The point of this is that there is a dependency issue that currently forces wireless-tools to be installed on machines with *NO* wireless capability. This does *NOT* make sense. Whether the fault lies with how wireless-tools is packaged up, or in the dependencies of other packages (such as rhpl) doesn't matter to Joe User. It doesn't particularly matter to me - I'm just reporting this situation in the hope that someone who knows the particular area will be able to sort something out. I don't accept that wireless tools, libs or anything should be a requirement of a basic install on a system that has no wireless capabilities. I also don't see it as anything to do with "luck". A dependency tree that forces the installation of packages that are not required is a badly built dependency tree. Citing the dependency of system-config-network on wireless-libs just highlights the issue. Wireless is a FORM of network. I shouldn't have to have all forms of network installed to be able to use system-config-network. In a wired-only environment, it is pointless to force the install of wireless packages based on such a dependency. In that case, a view needs to be taken as to whether system- config-network should be split to ensure the wireless functionallity is installed only when really required.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Changing this to Fedora 11. Still an issue in my mind, despite the rather pedantic responses from before. My current dependencies on wireless-tools are: Dependencies Resolved =============================================================================== Package Arch Version Repository Size =============================================================================== Removing: wireless-tools x86_64 1:29-4.fc11 installed 206 k Removing for dependencies: firstboot x86_64 1.106-1.fc11 installed 778 k kmod-nvidia x86_64 185.18.14-1.fc11.1 installed 0.0 kmod-nvidia-2.6.29.4-167.fc11.x86_64 x86_64 185.18.14-1.fc11 installed 12 M kmod-nvidia-2.6.29.5-191.fc11.x86_64 x86_64 185.18.14-1.fc11.1 installed 12 M livna-config-display noarch 0.0.23-1.fc11 installed 268 k rhpl x86_64 0.221-1 installed 998 k rhpxl x86_64 1.12-2.fc11 installed 340 k system-config-boot x86_64 0.3.1-1.fc11 installed 161 k system-config-date noarch 1.9.38-1.fc11 installed 2.8 M system-config-date-docs noarch 1.0.7-1.fc11 installed 17 M system-config-display noarch 1.1.3-2.fc11 installed 752 k system-config-firewall noarch 1.2.16-2.fc11 installed 534 k system-config-firewall-tui noarch 1.2.16-2.fc11 installed 2.0 M system-config-keyboard noarch 1.2.15-8.fc11 installed 205 k system-config-language noarch 1.3.2-5.fc11 installed 355 k system-config-lvm noarch 1.1.4-5.1.fc11 installed 2.9 M system-config-network noarch 1.5.97-1.fc11 installed 2.1 M system-config-network-tui noarch 1.5.97-1.fc11 installed 5.0 M system-config-nfs noarch 1.3.44-1.fc11 installed 666 k system-config-nfs-docs noarch 1.0.6-1.fc11 installed 8.6 M system-config-rootpassword noarch 1.99.4-4.fc11 installed 188 k system-config-users noarch 1.2.87-1.fc11 installed 1.7 M system-config-users-docs noarch 1.0.6-1.fc11 installed 9.4 M xorg-x11-drv-nvidia x86_64 185.18.14-2.fc11 installed 8.4 M xorg-x11-drv-nvidia-libs x86_64 185.18.14-2.fc11 installed 24 M Transaction Summary =============================================================================== Install 0 Package(s) Update 0 Package(s) Remove 26 Package(s) Despite my lost focus on this issue, I still think that it's something that can be resolved rather than ignored.
Once bug 508951 is done, this should resolve itself.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
rhpl is dead, this should be fixed in F-13.