1 |
On Sat, 2005-05-21 at 09:22 +0100, Stroller wrote: |
2 |
> Surely a user who emerges prism54-firmware will depend upon |
3 |
> wireless-tools? |
4 |
|
5 |
No. |
6 |
|
7 |
They could use wpa_supplicant. They could also be setting up their card |
8 |
as an access point or as a sniffer device. They could even be allowing |
9 |
it to roam to the nearest unsecured network, which is, I believe, the |
10 |
default and will work even without wireless-tools. |
11 |
|
12 |
> > "The firmware itself does not depend on wireless-tools for operation. |
13 |
> > DEPEND/RDEPEND/PDEPEND in ebuilds are not for what you might |
14 |
> > want to use along with the package in question - it is for technical |
15 |
> > dependencies such as libraries and utilities." |
16 |
> |
17 |
> Ok... so you're saying that the way to resolve this is to have a |
18 |
> variable called USER_WILL_DEPEND or similar? |
19 |
|
20 |
Like I said above, there's lots of packages a user *could* want to use |
21 |
with the firmware. That doesn't mean that we should be putting them all |
22 |
into a *DEPEND. |
23 |
|
24 |
> > ....The firmware, which in 2 of these |
25 |
> > cases are in seperate packages, do not depend on wireless-tools. |
26 |
> |
27 |
> Y'see I'm just not getting why not. |
28 |
|
29 |
You said so yourself. Loading the firmware does not require |
30 |
wireless-tools. |
31 |
|
32 |
Thank of it this way. There are lots of options in the kernel that |
33 |
require you to download an external application for the option to be |
34 |
useful. However, the kernel does not *DEPEND on these, because they are |
35 |
not a *requirement* for building the kernel. They aren't even a |
36 |
requirement for using the kernel. |
37 |
|
38 |
Consider the "Help" of a kernel option sufficient "*DEPEND" information, |
39 |
if you will. |
40 |
|
41 |
> A user can install Gentoo, compile the prism54 drivers in to his |
42 |
> kernel, emerge the prism54-firmware ebuild and not have |
43 |
> wireless-tools. Yet having emerged the prism54-firmware the user has |
44 |
> indicated to Portage that, yes, indeed, he intends upon using a |
45 |
> wireless network card. |
46 |
|
47 |
Agreed. |
48 |
|
49 |
He also can still use it in many ways without wireless-tools. |
50 |
|
51 |
> As I understand it, the firmware can be uploaded to a wireless card |
52 |
> without the wireless-tools, but nothing useful can be done with either |
53 |
> the wireless card or the firmware without it. |
54 |
|
55 |
Unless the person wanted to use their card in any of the ways I have |
56 |
stated above. |
57 |
|
58 |
> Are you telling me this understanding is wrong? |
59 |
|
60 |
Yes. |
61 |
|
62 |
> The distinction between driver & firmware kinda dawned on me whilst |
63 |
> writing my original email, but I don't the practical implications. The |
64 |
> user needs wireless-tools in either case, right? |
65 |
|
66 |
No. |
67 |
|
68 |
> Is it the case instead that using DEPEND, RDEPEND or PDEPEND would |
69 |
> break something else if used to indicate the user's need? Hence a |
70 |
> variable called USER_WILL_DEPEND would be more suitable? |
71 |
|
72 |
As stated above. The ebuild is correct, as are the maintainers. There |
73 |
is no need for a USER_WILL_DEPEND, as that would be the exact same as |
74 |
RDEPEND. If it isn't a dependency, then it doesn't go into *DEPEND. |
75 |
|
76 |
> This is just melting my head, because I just don't see what I've got |
77 |
> wrong here - both you & brix have told me so, so you must be right. |
78 |
> Could you please explain more slowly for me? |
79 |
|
80 |
Hopefully, I have done so. |
81 |
|
82 |
> > And for |
83 |
> > a last example which I just thought of... ndiswrapper acts the sameway. |
84 |
> > Considering the Windows drivers are more of a "firmware" and |
85 |
> > ndiswrapper |
86 |
> > is the driver. |
87 |
> |
88 |
> Mostly for ideological reasons I tend to ignore NDISwrapper, but I see |
89 |
> that emerging it pulls in wireless-tools. This seems correct and |
90 |
> sensible to me - by emerging NDISwrapper the user has indicated that he |
91 |
> intends on installing a wireless card (right?), so the ebuild provides |
92 |
> him with the tools he will need to set its SSID & WEP key. |
93 |
|
94 |
-- |
95 |
Chris Gianelloni |
96 |
Release Engineering - Strategic Lead/QA Manager |
97 |
Games - Developer |
98 |
Gentoo Linux |