[gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools

[gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools

[Stroller]

Hi,

I thought about filing another bug about this, but decided I'd rather 
whine about it in public to get a better airing / flaming / 
understanding of the issues.

Using a wireless network card under linux may require various 
components:
- the hardware driver itself
- a firmware to be uploaded to the card via hotplug
- hotplug
- as I understand it: wireless-tools to actually configure the SSID, 
WEP key
   &c of the wireless network to be connected to.

Is my understanding of the last point incorrect?
Because it seems to me there's little point in emerging the ebuild for 
a wireless network card unless it's going to be connected to a wireless 
network, and in that case the least thing that's going to need setting 
is the SSID & IP address.

Prism54 is the name of one such driver, and because it is being 
incorporated into the main kernel tree there exists more than one 
ebuild for it - one which includes the hardware driver module itself, 
and one for one for users of the latest kernels who only require the 
firmware.

These two ebuilds take a different approach to wireless-tools - one 
requires it as a depend, the other does not:

	$ emerge -pv prism54
	
	These are the packages that I would merge, in order:
	
	Calculating dependencies ...done!
	[ebuild  N    ] sys-apps/hotplug-20040923  43 kB
	[ebuild  N    ] net-wireless/prism54-firmware-1.0.4.3  91 kB
	[ebuild  N    ] net-wireless/wireless-tools-27  +nls 0 kB
	[ebuild  N    ] net-wireless/prism54-20050125  -pcmcia 74 kB
	
	Total size of downloads: 210 kB
	$ emerge -pv prism54-firmware
	
	These are the packages that I would merge, in order:
	
	Calculating dependencies ...done!
	[ebuild  N    ] sys-apps/hotplug-20040923  43 kB
	[ebuild  N    ] net-wireless/prism54-firmware-1.0.4.3  91 kB
	
	Total size of downloads: 135 kB
	$

I filed a bug <http://bugs.gentoo.org/show_bug.cgi?id=87197> about this 
a few weeks ago, and was told:
   "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."

Now, as I say, I can see few reasons to install the prism54 firmware & 
not use wireless-tools - were you to use a Prism54 card in passive-mode 
as a packet-sniffer then I suppose it's possible, but most users want 
to `emerge prism54-firmware` and have it "Just Work (tm)".

Having been blown out on my bug I took it deeply personally, then 
shrugged & forgot about it. Forgot about it, that is, until I went to 
setup the wireless card in a freshly-installed laptop today:

	$ emerge -pv acx100
	
	These are the packages that I would merge, in order:
	
	Calculating dependencies ...done!
	[ebuild  N    ] net-wireless/wireless-tools-27  +nls 0 kB
	[ebuild  N    ] net-wireless/acx100-0.2.0_pre8-r5  -pcmcia 275 kB
	
	Total size of downloads: 275 kB
	$

It seems to me that I could now file a bug about acx100 saying that it 
"incorrectly depends upon wireless-tools" but - unless I'm 
misunderstanding something pertinent - I still think this is the wrong 
behaviour. Whether I'm installing a prism54 or an acx100 card in my 
machine, I'm still going to need to iwconfig them to the right wireless 
network.

The ebuild for the Ralink cards seems to feel the same way:

	$ emerge -pv rt2500
	
	These are the packages that I would merge, in order:
	
	Calculating dependencies ...done!
	[ebuild  N    ] net-wireless/wireless-tools-27  +nls 0 kB
	[ebuild  N    ] net-wireless/rt2500-1.1.0_beta2-r1  +qt 286 kB
	
	Total size of downloads: 286 kB
	$

So, anyway, I don't intend for this posting to be a criticism of brix 
for blowing me out on my bug, I  just want to understand better. Can 
anyone tell me if there's a logical reason for wireless-tools to be 
treated differently by these 4 packages? If you "might want to use" 
wireless-tools in almost every circumstance with the prism54-firmware & 
this isn't covered by DEPEND/RDEPEND/PDEPEND, can we have a new 
variable "YOU_MIGHT_WANT_TO_USE_DEPEND", please?

Stroller.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools

[Doug Goldstein]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Stroller wrote:
> Hi,
> 
..... farrrrr tooooo 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 <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools

[Roy Marples]

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

[Stroller]

On May 21, 2005, at 6:25 am, Doug Goldstein wrote:
> Stroller wrote:
>> Hi,
>>
> ..... farrrrr tooooo 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

[Stroller]

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

[Roy Marples]

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 3866 bytes --]

On Sat, 2005-05-21 at 09:22 +0100, Stroller wrote:
>     Surely a user who emerges prism54-firmware will depend upon 
> wireless-tools?

No.

They could use wpa_supplicant.  They could also be setting up their card
as an access point or as a sniffer device.  They could even be allowing
it to roam to the nearest unsecured network, which is, I believe, the
default and will work even without 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?

Like I said above, there's lots of packages a user *could* want to use
with the firmware.  That doesn't mean that we should be putting them all
into a *DEPEND.

> > ....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.

You said so yourself.  Loading the firmware does not require
wireless-tools.

Thank of it this way.  There are lots of options in the kernel that
require you to download an external application for the option to be
useful.  However, the kernel does not *DEPEND on these, because they are
not a *requirement* for building the kernel.  They aren't even a
requirement for using the kernel.

Consider the "Help" of a kernel option sufficient "*DEPEND" information,
if you will.

> 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.

Agreed.

He also can still use it in many ways without wireless-tools.

> 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.

Unless the person wanted to use their card in any of the ways I have
stated above.

> Are you telling me this understanding is wrong?

Yes.

> 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?

No.

> 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?

As stated above.  The ebuild is correct, as are the maintainers.  There
is no need for a USER_WILL_DEPEND, as that would be the exact same as
RDEPEND.  If it isn't a dependency, then it doesn't go into *DEPEND.

> 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?

Hopefully, I have done so.

> > 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.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools

[Stroller]

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

[Allen Parker]

On 5/23/05, Stroller <stroller@stellar.eclipse.co.uk> wrote:
ahhhh <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