Bug 179348 - Move madwifi headers into madwifi-ng-tools
|
Bug#:
179348
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: steev@gentoo.org
|
Reported By: dsd@gentoo.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: Move madwifi headers into madwifi-ng-tools
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-05-21 19:27 0000
|
Currently the madwifi-ng ebuild installs the /usr/include/madwifi headers used
by wpa_supplicant and hostapd. This means that wpa_supplicant has to
conditionally depend on madwifi-ng, which is in itself nasty because madwifi-ng
has dependencies on kernel stuff -- this is an inconvenience when building
release media etc.
I think the headers should be installed by the madwifi-ng-tools ebuild and
wpa_supplicant/hostapd dependencies should be updated.
I just whipped up some patches to do as requested in this bug. They work for
me with the exception of hostapd-0.5.7-r1.patch which I did not test.
In the case of hostapd/wpa_supplicant ebuilds these changes should probably
just go into the existing ebuilds instead of a rather meaningless revbump.
Only submitted the patches this way for consistency/testing/etc.
the madwifi side of things is done.
Now madwifi-ng-tools don't emerge due to file collisions with madwifi-ng. A
blocker against older versions?
(In reply to comment #9)
> Now madwifi-ng-tools don't emerge due to file collisions with madwifi-ng. A
> blocker against older versions?
>
That was left out in the cvs commit. There is also a format error in the einfo
messages at the end.
(In reply to comment #9)
> Now madwifi-ng-tools don't emerge due to file collisions with madwifi-ng. A
> blocker against older versions?
A blocker is a bad thing because most users do not know how to correctly handle
it. Besides it braks automated updates.
Maybe we can remove the conflicting files in preinst?