Why does yum erase wireless-tools want to: Removing for dependencies: anaconda firstboot rhpl system-config-(boot,date,date-docs,firewall, firewall-tui,keyboard,kickstart,language,lvm, network,network-tui,rootpassword,users,users-docs)
This is a wired desktop, that has absolutely no need for wireless or indeed wpa-supplicant which want to remove: NetworkManager NetworkManager-gnome anaconda system-config-kickstart
I know --nodeps could be used, or indeed use "network service" but currently have no problems with NM
Bu how?, are they tied into so much.
Frank
Dne Sun, 21 Jun 2009 12:14:04 +0100 Frank Murphy frankly3d@gmail.com napsal(a):
Why does yum erase wireless-tools want to: Removing for dependencies: anaconda firstboot rhpl system-config-(boot,date,date-docs,firewall, firewall-tui,keyboard,kickstart,language,lvm, network,network-tui,rootpassword,users,users-docs)
This is a wired desktop, that has absolutely no need for wireless or indeed wpa-supplicant which want to remove: NetworkManager NetworkManager-gnome anaconda system-config-kickstart
I know --nodeps could be used, or indeed use "network service" but currently have no problems with NM
Bu how?, are they tied into so much.
Frank
Someone already requested this: https://bugzilla.redhat.com/show_bug.cgi?id=480558
Why does it bother you? The package is not that big.
Michal
On 21/06/09 12:57, Michal Schmidt wrote:
Someone already requested this: https://bugzilla.redhat.com/show_bug.cgi?id=480558
Good
Why does it bother you? The package is not that big.
It's not about size, it's about making sense. No wireless, therefore why wireless installed.
Michal
Frank
On Sun, 2009-06-21 at 13:01 +0100, Frank Murphy wrote:
On 21/06/09 12:57, Michal Schmidt wrote:
Someone already requested this: https://bugzilla.redhat.com/show_bug.cgi?id=480558
Good
Why does it bother you? The package is not that big.
It's not about size, it's about making sense. No wireless, therefore why wireless installed.
Same reason the kernel installs a lot of drivers. If you, in the future, plug something wireless in, it'll work.
It's also a question of maintainability. Sure, we could split up tons of packages and add code to all the tools to check runtime-availability of every tool they might use. But that's just insane, and increases the maintenance burden tremendously.
So the tradeoff is between the packagers maintaining an ugly patch that upstream probably won't care about, against making the 5% of people who really want to remove wireless-tools happy. Every change like this increases the maintenance burden, and I'd argue that it's simply not worth it. There's also value to being able to just plug hardware in and have it work without downloading additional software.
Dan
On 06/22/2009 10:14 AM, Dan Williams wrote:
It's also a question of maintainability. Sure, we could split up tons of packages and add code to all the tools to check runtime-availability of every tool they might use. But that's just insane, and increases the maintenance burden tremendously.
This is roughly what Gentoo does, right? Of course, Gentoo has the 'luxury' of re-compiling. But that just gets at, I think, that vanilla c isn't flexible enough to handle this dynamically. A Python app could do it pretty easily, IIRC. In that case, a Python implementation of a thing could conceivably compete for mindshare against the c version, given the inherent trade-offs.
One could imagine Feature: and Feature-Requires: tags in a spec that could be used to generate more complex dependency trees and automatically generate the proper set of package-foo.rpm files. Integrating this with yum and/or graphical package managers would certainly be a ton of work.
But to get to the thematic question, probably nobody (for large values of nobody) cares if any given package has a 40KB dependency. It's when you have a thousand packages that have a thousand unneeded dependencies, you increase the cost (time, disk, memory, cpu, bandwidth, electricity, complexity) to install, update, etc. and you wind up excluding very small computing devices in some cases.
I agree that making humans manage this would approach insanity. But does that necessarily preclude allowing computers to handle it?
-Bill
On 06/21/2009 07:57 AM, Michal Schmidt wrote:
Dne Sun, 21 Jun 2009 12:14:04 +0100 Frank Murphyfrankly3d@gmail.com napsal(a):
Why does yum erase wireless-tools want to: Removing for dependencies: anaconda firstboot rhpl system-config-(boot,date,date-docs,firewall, firewall-tui,keyboard,kickstart,language,lvm, network,network-tui,rootpassword,users,users-docs)
This is a wired desktop, that has absolutely no need for wireless or indeed wpa-supplicant which want to remove: NetworkManager NetworkManager-gnome anaconda system-config-kickstart
I know --nodeps could be used, or indeed use "network service" but currently have no problems with NM
Bu how?, are they tied into so much.
Frank
Someone already requested this: https://bugzilla.redhat.com/show_bug.cgi?id=480558
Why does it bother you? The package is not that big.
Michal
You are correct someone has already requested this change. That was almost six months ago, with little to no movement since then. Request for info from the maintainer for for 5+ months. Still has a status of new. Those are the problems I see with the bug report.
As to the bug itself, I can not and will not speak for why it bothers the OP. To answer your question though, it bothers me because I don't want packages on my machine I don't need. As it is my machine that is reason enough. Size is irrelevant.
With all due respect to Jeremy, I am removing his need info flag and assigning this bug as an RFE. This bug has the information needed to be actionable.
If someone feels this is incorrect, feel free to change it again (I don't do revision wars). Just have the courtesy to let me know why you made that change so we are on the same page for the future.
Edward (TK009)
TK009 wrote:
As to the bug itself, I can not and will not speak for why it bothers the OP. To answer your question though, it bothers me because I don't want packages on my machine I don't need.
If you need package XYZ and package XYZ needs package foo for whatever reason, then you need package foo, even if it doesn't intuitively make sense to you.
As it is my machine that is reason enough.
It's not, there's no rationale for removing small packages just because you think you don't need them (when you actually do, see above).
Size is irrelevant.
Huh? What harm is a package with a size in the KB range going to do? Just leave it sitting there instead of wasting your and our time whining about a dependency.
Kevin Kofler
On 06/23/2009 06:42 PM, Kevin Kofler wrote:
TK009 wrote:
As to the bug itself, I can not and will not speak for why it bothers the OP. To answer your question though, it bothers me because I don't want packages on my machine I don't need.
If you need package XYZ and package XYZ needs package foo for whatever reason, then you need package foo, even if it doesn't intuitively make sense to you.
As it is my machine that is reason enough.
It's not, there's no rationale for removing small packages just because you think you don't need them (when you actually do, see above).
Size is irrelevant.
Huh? What harm is a package with a size in the KB range going to do? Just leave it sitting there instead of wasting your and our time whining about a dependency.
Kevin Kofler
I didn't whine but if that is how you took it, good for you. You missed the point, so I wont bother explaining again. Let me decide how to use my time, you've made it clear how you want to use yours.
TK009
On Sun, 2009-06-21 at 11:40 -0400, TK009 wrote:
As to the bug itself, I can not and will not speak for why it bothers the OP. To answer your question though, it bothers me because I don't want packages on my machine I don't need. As it is my machine that is reason enough. Size is irrelevant.
It's important to note that this is not a reasonable expectation.
Think about what it means when you use a distribution which implements dependencies, and a dependency-resolving package manager like yum. What you are saying is 'I would like to trade the bit-by-bit control of what is installed on my computer for the convenience of letting someone else worry about it'. Simply by the act of using Fedora you essentially affirm that you actually _don't_ want to have permanent bit-by-bit control of this nature.
If you really want that, you should either run Slackware, LFS, or run Fedora but install everything from source or with rpm -Uvh (--nodeps when appropriate), and figure out dependencies yourself.
As long as you cede the control of the decision of what software really 'requires' other software to your distribution, you should recognize that you can't then use "I should have that control" as an argument when talking about distribution dependencies. It's fine to suggest that such-and-such a dependency shouldn't really be there, but it's not fine to justify this by saying "I should have control over what gets installed", because the whole point of dependencies is to save you the pain of worrying about that.
Remember that ultimately Fedora _does_ grant you access to that level of control, should you choose to use it: rpm -e --nodeps is available and does what it says on the tin. The trade-off is you get the responsibility along with the power. :)
On 06/23/2009 07:12 PM, Adam Williamson wrote:
On Sun, 2009-06-21 at 11:40 -0400, TK009 wrote:
As to the bug itself, I can not and will not speak for why it bothers the OP. To answer your question though, it bothers me because I don't want packages on my machine I don't need. As it is my machine that is reason enough. Size is irrelevant.
It's important to note that this is not a reasonable expectation.
Think about what it means when you use a distribution which implements dependencies, and a dependency-resolving package manager like yum. What you are saying is 'I would like to trade the bit-by-bit control of what is installed on my computer for the convenience of letting someone else worry about it'. Simply by the act of using Fedora you essentially affirm that you actually _don't_ want to have permanent bit-by-bit control of this nature.
If you really want that, you should either run Slackware, LFS, or run Fedora but install everything from source or with rpm -Uvh (--nodeps when appropriate), and figure out dependencies yourself.
As long as you cede the control of the decision of what software really 'requires' other software to your distribution, you should recognize that you can't then use "I should have that control" as an argument when talking about distribution dependencies. It's fine to suggest that such-and-such a dependency shouldn't really be there, but it's not fine to justify this by saying "I should have control over what gets installed", because the whole point of dependencies is to save you the pain of worrying about that.
Remember that ultimately Fedora _does_ grant you access to that level of control, should you choose to use it: rpm -e --nodeps is available and does what it says on the tin. The trade-off is you get the responsibility along with the power. :)
Good idea
On 24/06/09 13:30, TK009 wrote:
Remember that ultimately Fedora _does_ grant you access to that level of control, should you choose to use it: rpm -e --nodeps is available and does what it says on the tin. The trade-off is you get the responsibility along with the power. :)
Good idea
As the original OP, original concern has been sorted. Even thought I have purely wired on a number of boxes. There are others, probably the majority at this stage, who use\need both eth\wlan.
I would be a bit concerned though, if what Jef's scenario comes through:
"If wired becomes optional", https://www.redhat.com/archives/fedora-devel-list/2009-June/msg01739.html
in the future, maybe not included by default?
Frank
TK009 wrote:
[...] it bothers me because I don't want packages on my machine I don't need. As it is my machine that is reason enough. Size is irrelevant.
Hate to say it, but... if this is the case, you want (need) Gentoo. Fedora (and most pre-packaged distros) is going to pull dependencies for optional features.
The alternative is either: - build multiple packages for each combination of optional features - check for everything at runtime
Both have significant drawbacks. The latter has the further disadvantage (a problem we /already/ have, I'll add) that it makes it hard to discover that something can be enhanced by addition of some optional package.
At best, you can do something in a small number of significant cases. I tend to think deps should be split when something especially useful (e.g. NetworkManager) is hanging onto an entire chain of potentially useless functionality (yes, like wireless... or bluetooth) that can amount to a large number of packages and/or used space. As another example, kcalc requiring foomatic is a particular pet peeve of mine. (But wpa_supplicant is probably not worth it, both because of size, and because - as elsewhere noted - it might be needed on wired. Printing support is another matter... at least on size it is around 100 MB.)
But in general, if you want a super-lean system, you need to roll your own packages with the exact dependency set you want.
On Sun, 2009-06-21 at 12:14 +0100, Frank Murphy wrote:
Why does yum erase wireless-tools want to: Removing for dependencies: anaconda firstboot rhpl system-config-(boot,date,date-docs,firewall, firewall-tui,keyboard,kickstart,language,lvm, network,network-tui,rootpassword,users,users-docs)
This is a wired desktop, that has absolutely no need for wireless or indeed wpa-supplicant which want to remove: NetworkManager NetworkManager-gnome anaconda system-config-kickstart
I know --nodeps could be used, or indeed use "network service" but currently have no problems with NM
Bu how?, are they tied into so much.
Frank
I'm not sure about most of these, but I'd like to note that wpa-supplicant is not a wireless-only tool (that one of your sentences seem to imply). I use it at dorm to authenticate to wired network (as well as at home to authenticate to home wifi network). And because some NM features clearly require its presence, it would be broken if it did not require it.
Martin
On 21/06/09 12:59, Martin Sourada wrote:
I'm not sure about most of these, but I'd like to note that wpa-supplicant is not a wireless-only tool (that one of your sentences seem to imply). I use it at dorm to authenticate to wired network(as well as at home to authenticate to home wifi network). And because some NM features clearly require its presence, it would be broken if it did not require it.
Then the description need changing:
Description wpa_supplicant is a WPA Supplicant for Linux, BSD and Windows with support for WPA and WPA2 (IEEE 802.11i / RSN). Supplicant is the IEEE 802.1X/WPA component that is used in the client stations. It implements key negotiation with a WPA Authenticator and it controls the roaming and IEEE 802.11 authentication/association of the wlan : driver.
Martin
Frank
On Sun, 2009-06-21 at 13:10 +0100, Frank Murphy wrote:
Then the description need changing:
Description wpa_supplicant is a WPA Supplicant for Linux, BSD and Windows with support for WPA and WPA2 (IEEE 802.11i / RSN). Supplicant is the IEEE 802.1X/WPA component that is used in the client stations. It implements key negotiation with a WPA Authenticator and it controls the roaming and IEEE 802.11 authentication/association of the wlan : driver.
Yeah, the "wlan driver" is not apparently the only one where wpa_supplicant is used for authentication, although the usage of IEEE 802.1x on wired networks is probably rather rare.
Frank
Martin
On Sun, 2009-06-21 at 13:59 +0200, Martin Sourada wrote:
On Sun, 2009-06-21 at 12:14 +0100, Frank Murphy wrote:
Why does yum erase wireless-tools want to: Removing for dependencies: anaconda firstboot rhpl system-config-(boot,date,date-docs,firewall, firewall-tui,keyboard,kickstart,language,lvm, network,network-tui,rootpassword,users,users-docs)
This is a wired desktop, that has absolutely no need for wireless or indeed wpa-supplicant which want to remove: NetworkManager NetworkManager-gnome anaconda system-config-kickstart
I know --nodeps could be used, or indeed use "network service" but currently have no problems with NM
Bu how?, are they tied into so much.
Frank
I'm not sure about most of these, but I'd like to note that wpa-supplicant is not a wireless-only tool (that one of your sentences seem to imply). I use it at dorm to authenticate to wired network (as well as at home to authenticate to home wifi network). And because some NM features clearly require its presence, it would be broken if it did not require it.
Which is exactly why NM requires the supplicant, because without it, you can't connect to 802.1x-protected *wired* networks like yours, and you can't just plug in a wifi adapter and have it work out of the box.
Dan
On Sun, Jun 21, 2009 at 12:14:04PM +0100, Frank Murphy wrote:
Why does yum erase wireless-tools want to: Removing for dependencies: anaconda firstboot rhpl system-config-(boot,date,date-docs,firewall, firewall-tui,keyboard,kickstart,language,lvm, network,network-tui,rootpassword,users,users-docs)
This is a wired desktop, that has absolutely no need for wireless
If a tool needs something to perform one of its functions it needs it. There isn't a "anaconda-no-wireless" package, etc.
Hth...
John
On Sun, Jun 21, 2009 at 6:50 AM, John W. Linvillelinville@redhat.com wrote:
If a tool needs something to perform one of its functions it needs it. There isn't a "anaconda-no-wireless" package, etc.
This speaks deeply to a cultural understanding as to what the concept of networking is.
It seems obvious there are people who would like to consider wireless as "optional." as this is an historic artifact of how networking tech has developed over time. I wonder, have we reached the point where other people have started to consider a wired network "optional" as well?
-jef
On 06/21/2009 05:56 PM, Jeff Spaleta wrote:
On Sun, Jun 21, 2009 at 6:50 AM, John W. Linvillelinville@redhat.com wrote:
If a tool needs something to perform one of its functions it needs it. There isn't a "anaconda-no-wireless" package, etc.
This speaks deeply to a cultural understanding as to what the concept of networking is.
It seems obvious there are people who would like to consider wireless as "optional." as this is an historic artifact of how networking tech has developed over time. I wonder, have we reached the point where other people have started to consider a wired network "optional" as well?
-jef
This is a good question. Laptops are becoming the norm if not already so, add "smart devices" and wireless is looking more like the standard rather than exception. We are not there quite yet though.
To most (almost all) desktop users, wireless packages are superfluous. That is generally not the case with a laptop user. As long as they have the hardware to support both, they will continue to need (want) both. So no, I do not believe we've reached a point where wired would be concidered optional, not yet anyway.
TK009
If a tool needs something to perform one of its functions it needs it. There isn't a "anaconda-no-wireless" package, etc.
This speaks deeply to a cultural understanding as to what the concept of networking is.
It seems obvious there are people who would like to consider wireless as "optional." as this is an historic artifact of how networking tech has developed over time. I wonder, have we reached the point where other people have started to consider a wired network "optional" as well?
-jef
This is a good question. Laptops are becoming the norm if not already so, add "smart devices" and wireless is looking more like the standard rather than exception. We are not there quite yet though.
To most (almost all) desktop users, wireless packages are superfluous. That is generally not the case with a laptop user. As long as they have the hardware to support both, they will continue to need (want) both. So no, I do not believe we've reached a point where wired would be concidered optional, not yet anyway.
I would agree, just about all NetBooks (possibly all) still come with wired ethernet ports and given their price point I would expect that that platform to be the one to drop the wired ports first. Also a nummber of other devices that have only wireless still support usb ethernet out of the box to provide wired support.
Peter
Peter Robinson wrote:
I would agree, just about all NetBooks (possibly all) still come with wired ethernet ports and given their price point I would expect that that platform to be the one to drop the wired ports first. Also a nummber of other devices that have only wireless still support usb ethernet out of the box to provide wired support.
Design costs aside, the cost of putting an RJ45 NIC on something was around $10 several years ago. I suspect the marginal (per-unit) cost to OEM's is awfully close to nil.
Besides, what about hotels with wired but no wireless? What about people like me that strongly prefer wired to wireless? ;-)
You're probably right that netbooks will drop RJ45 first, but I suspect not for a while, unless form factor is the problem.