From: Chris Gianelloni <wolf31o2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools
Date: Mon, 23 May 2005 14:58:44 -0400 [thread overview]
Message-ID: <1116874724.14290.99.camel@cgianelloni.nuvox.net> (raw)
In-Reply-To: <682beff572e281df9d2954eec0249b52@stellar.eclipse.co.uk>
[-- 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 --]
next prev parent reply other threads:[~2005-05-23 18:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-21 4:06 [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools Stroller
2005-05-21 5:25 ` Doug Goldstein
2005-05-21 8:22 ` Stroller
2005-05-23 18:58 ` Chris Gianelloni [this message]
2005-05-21 7:47 ` Roy Marples
2005-05-21 8:25 ` Stroller
2005-05-23 10:04 ` Roy Marples
2005-05-24 3:32 ` Stroller
2005-05-24 7:51 ` Allen Parker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1116874724.14290.99.camel@cgianelloni.nuvox.net \
--to=wolf31o2@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox