Re: [gentoo-dev] Wireless driver / firmware ebuilds wireless-tools
On 5/23/05, Stroller [EMAIL PROTECTED] wrote: a snipsnipsnipsnipsnip But in any case, the functionality contained in wpa_supplicant covers my arguments, and I apologise for not being aware of it. Stroller Since you were the only person that is not a gentoo dev to post on this topic, I will give you an acceptable sequence of events, as I believe that this medium wasn't the proper venue for your particular complaint: 1. emerge an irc client of your preference 2. connect to irc.freenode.net 3. join #gentoo-laptop 4. have this discussion over a period of minutes instead of days, and off-list 5. keep other people on the list from becoming annoyed with your refusal to accept a given answer. 6. if you *really* have a problem accepting the given answer, read gentoo's policies with regards to ebuilds, then, if you *still* have issue, take it up with devrel. infowolfe via irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wireless driver / firmware ebuilds wireless-tools
On Sat, 2005-05-21 at 09:25 +0100, Stroller wrote: What's the difference between wpa_supplicant wireless-tools, then? Both do the same job - provide the tools to configure your wireless card. wpa_supplicant is a daemon that runs in the background and when it associates with an AP in your list it applies the pre-defined security settings. Any current wireless security on SOHO boxes is supported. wireless-tools is a set of programs that configure your card per your settings and call it a day. Gentoo baselayout does some rudimentry scanning and AP selection, so it's not that bad. Only WEP security is supported. Could ipw2200 (theoretically, as a virtual, or at some point in the future) depend upon wpa_supplicant instead? That would be upto the package maintainers to decide, but I can't think of any reason why not. Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wireless driver / firmware ebuilds wireless-tools
On May 23, 2005, at 11:04 am, Roy Marples wrote: On Sat, 2005-05-21 at 09:25 +0100, Stroller wrote: What's the difference between wpa_supplicant wireless-tools, then? Both do the same job - provide the tools to configure your wireless card. wpa_supplicant is a daemon that runs in the background and when it associates with an AP in your list it applies the pre-defined security settings. Any current wireless security on SOHO boxes is supported. wireless-tools is a set of programs that configure your card per your settings and call it a day. Gentoo baselayout does some rudimentry scanning and AP selection, so it's not that bad. Only WEP security is supported. Thanks to both yourself Mr Gianelloni for clarification. I'm sorry for the confusion. Sounds like wpa_supplicant is the more sophisticated software - I shall look into it. One minor point: On May 23, 2005, at 7:58 pm, Chris Gianelloni wrote: Surely a user who emerges prism54-firmware will depend upon wireless-tools? ... They could also be setting up their card as an access point or as a sniffer device. I think the access-point will need `iwconfig` (or similar if it's provided by wpa_supplicant) to set the SSID (optionally) WEP key. That's what I use around here, anyway. I intended to cover the sniffing aspect in an earlier posting - it's a fairly niche usage, and I'd imagine it to be rare that a machine will be dedicated to sniffing for networks never used to connect to one. But in any case, the functionality contained in wpa_supplicant covers my arguments, and I apologise for not being aware of it. Stroller -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wireless driver / firmware ebuilds wireless-tools
On Sat, 2005-05-21 at 05:06 +0100, Stroller wrote: - as I understand it: wireless-tools to actually configure the SSID, WEP key wpa_supplicant can do this as well which makes wireless-tools optional Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wireless driver / firmware ebuilds wireless-tools
On May 21, 2005, at 6:25 am, Doug Goldstein wrote: Stroller wrote: Hi, . far to long. Yeah, sorry... I've always been pedantic. It's a real hard habit to shift. In summary and simple conclusion, yes you are wrong. So that makes 2 out of the 4 or 5 active Mobile herd devs who say you're wrong. Sorry again. Maybe I didn't make myself clear. I didn't mean to say in my posting I'm right, but rather I intended to ask: Surely a user who emerges prism54-firmware will depend upon wireless-tools? The firmware itself does not depend on wireless-tools for operation. DEPEND/RDEPEND/PDEPEND in ebuilds are not for what you might want to use along with the package in question - it is for technical dependencies such as libraries and utilities. Ok... so you're saying that the way to resolve this is to have a variable called USER_WILL_DEPEND or similar? The firmware, which in 2 of these cases are in seperate packages, do not depend on wireless-tools. Y'see I'm just not getting why not. A user can install Gentoo, compile the prism54 drivers in to his kernel, emerge the prism54-firmware ebuild and not have wireless-tools. Yet having emerged the prism54-firmware the user has indicated to Portage that, yes, indeed, he intends upon using a wireless network card. As I understand it, the firmware can be uploaded to a wireless card without the wireless-tools, but nothing useful can be done with either the wireless card or the firmware without it. Are you telling me this understanding is wrong? The distinction between driver firmware kinda dawned on me whilst writing my original email, but I don't the practical implications. The user needs wireless-tools in either case, right? Is it the case instead that using DEPEND, RDEPEND or PDEPEND would break something else if used to indicate the user's need? Hence a variable called USER_WILL_DEPEND would be more suitable? This is just melting my head, because I just don't see what I've got wrong here - both you brix have told me so, so you must be right. Could you please explain more slowly for me? And for a last example which I just thought of... ndiswrapper acts the sameway. Considering the Windows drivers are more of a firmware and ndiswrapper is the driver. Mostly for ideological reasons I tend to ignore NDISwrapper, but I see that emerging it pulls in wireless-tools. This seems correct and sensible to me - by emerging NDISwrapper the user has indicated that he intends on installing a wireless card (right?), so the ebuild provides him with the tools he will need to set its SSID WEP key. Stroller. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wireless driver / firmware ebuilds wireless-tools
On May 21, 2005, at 8:47 am, Roy Marples wrote: On Sat, 2005-05-21 at 05:06 +0100, Stroller wrote: - as I understand it: wireless-tools to actually configure the SSID, WEP key wpa_supplicant can do this as well which makes wireless-tools optional Ah, expletive! Please excuse my last email, then, which went from my outbox just a few seconds ago. What's the difference between wpa_supplicant wireless-tools, then? Could ipw2200 (theoretically, as a virtual, or at some point in the future) depend upon wpa_supplicant instead? Stroller. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wireless driver / firmware ebuilds wireless-tools
Stroller wrote: Hi, . far to long. Stroller. In summary and simple conclusion, yes you are wrong. So that makes 2 out of the 4 or 5 active Mobile herd devs who say you're wrong. brix is 100% correct. Let me give you an explaination The firmware itself does not depend on wireless-tools for operation. DEPEND/RDEPEND/PDEPEND in ebuilds are not for what you might want to use along with the package in question - it is for technical dependencies such as libraries and utilities. There ya go. Explained. In fact, you actually explained the logical reason in your e-mail, surprised you didn't notice it. But I'll highlight it for you. acx100 and rt2500 contain drivers. prism54 is a driver. ipw2200 is a driver. They depend on wireless-tools. The firmware, which in 2 of these cases are in seperate packages, do not depend on wireless-tools. And for a last example which I just thought of... ndiswrapper acts the sameway. Considering the Windows drivers are more of a firmware and ndiswrapper is the driver. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
