Bug 443494 - Cannot remove wireless-tools without removing essential packages
Cannot remove wireless-tools without removing essential packages
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: wireless-tools (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
Depends On: rhplectomy
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-21 16:34 EDT by Duncan Innes
Modified: 2010-04-27 10:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-27 10:46:51 EDT
Type: ---
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 Duncan Innes 2008-04-21 16:34:17 EDT
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.
Comment 1 Dan Williams 2008-04-21 22:55:18 EDT
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?
Comment 2 Bill Nottingham 2008-04-21 23:01:42 EDT
You could split out the libs if you wanted to, I suppose. That being said,
there's no way this is a security issue.
Comment 3 Duncan Innes 2008-04-22 03:46:14 EDT
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.
Comment 4 Christopher Aillon 2008-04-22 18:41:14 EDT
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
Comment 5 Duncan Innes 2008-04-23 04:21:53 EDT
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.
Comment 6 Christopher Aillon 2008-04-23 11:06:55 EDT
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
Comment 7 Duncan Innes 2008-04-23 11:49:46 EDT
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.

Comment 8 Christopher Aillon 2008-04-23 13:07:16 EDT
So, um, file bugs on those apps to not depend on it?
Comment 9 Christopher Aillon 2008-04-23 13:08:14 EDT
Though really, it's that rhpl depends on it.  And system-config* depends on rhpl.
Comment 10 Duncan Innes 2008-04-23 14:05:08 EDT
Or split the wireless-tools package as was suggested by Dan Williams and Bill 
Nottingham?

Comment 11 Christopher Aillon 2008-04-23 14:55:10 EDT
But you still won't be able to remove the wireless support from the distro if
other programs still require it.
Comment 12 Duncan Innes 2008-04-23 17:11:42 EDT
*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.
Comment 13 Christopher Aillon 2008-04-23 17:38:27 EDT
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.
Comment 14 Duncan Innes 2008-04-29 05:06:21 EDT
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.
Comment 15 Bug Zapper 2008-05-14 05:53:08 EDT
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
Comment 16 Bug Zapper 2009-06-09 20:20:18 EDT
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
Comment 17 Bug Zapper 2009-07-14 11:13:59 EDT
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.
Comment 18 Duncan Innes 2009-07-14 11:30:03 EDT
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.
Comment 19 Bill Nottingham 2009-07-14 11:34:09 EDT
Once bug 508951 is done, this should resolve itself.
Comment 20 Bug Zapper 2010-04-27 08:00:45 EDT
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
Comment 21 Bill Nottingham 2010-04-27 10:46:51 EDT
rhpl is dead, this should be fixed in F-13.

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