|
Bugzilla – Full Text Bug Listing |
| Summary: | When Atheros card detected, give a hint about binary drivers | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Dominique Leuenberger <dimstar> |
| Component: | libzypp | Assignee: | Michal Zugec <mzugec> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Enhancement | ||
| Priority: | P4 - Low | CC: | andreas.hanke, dmacvicar, holgi, jsrain, kkaempf, ma |
| Version: | Alpha 2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Dominique Leuenberger
2006-10-31 10:11:20 UTC
AFAIK libzypp does support hardware dependencies, but the way this works is usually that some package has an "enhances" dependency on that hardware. If there is no package that could have this "enhances" dependency (and this is the point here), the only way out I see is to create a pseudo package - one that is basically empty or consists only of a "README" file - that has that "enhances" dependency and either a "notify" text set or, better, a license the user has to confirm. Even though "install notify" might sound better at first, that is only displayed if the user clicks directly on that package, so this won't work out. A license OTOH the user will have to confirm, i.e. he will be prompted in any case. That doesn't sound to bad to me. For it being completely perfect, the maintainer of the MadWifi Packages most probably should mark the dummy package as 'obsolete' by his packages. And having it always popping up on installation is much better than just having the notify that it could be available. The user really should be informed about that. Klaus, what's your opinion on this? The 'dummy package approach' is probably the best we can do currently. This dummy package should also recommend (weak requires) the madwifi package so the real driver gets installed if available. Going forward, we could make messages (as used in patches) first-class objects to implement hardware-dependant user notifications. *** Bug 119812 has been marked as a duplicate of this bug. *** -> 10.3 *** Bug 307745 has been marked as a duplicate of this bug. *** mass reopening of later+remind bugs of 11.0 Certainly not an issue that could be solved on yast2-network level - this is something for libzypp maintainers (maybe pulling in related packages when certain hardware is detected already works somehow, but I'm really no expert in this). Pulling in a package based on existing hardware is done for all sort of drivers, based on the Supplements: tag. The 'problem' here is that for Atheros, and also broadcom cards, a binary blob needs to be installed in plus. For the bcm cards there is a simple script (most likely also for atheros) (for bcm it's /usr/sbin/install_bcm43xx_firmware ) The 'problem' is that a 'typical' user installing openSUSE does not know about the existance of this script and he neesd to be informed or even 'supported' in performing this step. (b43-fwcutter is automatically installed if you have a bcm chip, but it's presence remains a mystery for most users...) (In reply to comment #10) > Certainly not an issue that could be solved on yast2-network level - this is > something for libzypp maintainers (maybe pulling in related packages when > certain hardware is detected already works somehow, but I'm really no expert in > this). Yes, this would be (an already working) solution, if the package was in the main distro repository. But that's not the case, and therefore nothing for libzypp, this must be done elsewhere (zypp is not intened to produce such messages, nevertheless, it can be probably be used to check for such hardware, if looking for a unique modalias in system's 'provides' is enough to do this). yast2-network looks to me like a good place - it could inform the user during the configuration of network. Bubli, Jirko, Duncan, please decide whether to do it in yast or elsewhere. BTW, it would be nice if we could develop some (or find an existing) system-wide solution for these kinds of things and just use that from yast or anywhere else. Hmm, would http://en.opensuse.org/Software_Management/Code11/Scripts_and_Messages be of help ? c#13: well, this is a facility used by packages being installed to run scripts and show messages. Do you suggest some package should detect if there is the wifi card present when being installed, so that libzypp displays some message? Does not look like the right way to me, but maybe i don't get what you mean. (In reply to comment #14) > c#13: well, this is a facility used by packages being installed to run scripts > and show messages. Do you suggest some package should detect if there is the > wifi card present when being installed, so that libzypp displays some message? Right. A message- (or script-)only package, using hardware dependencies (http://en.opensuse.org/Software_Management/Dependencies/Hardware) to trigger its installation and then either pointing the user to documentation or running a script (i.e. like fetchmsttffonts) to download whatever is needed. Otoh, smolt (http://en.wikipedia.org/wiki/Smolt_%28Linux%29) might offer a more generic (less suse-specific) way to handle such situations. Vlado, is this still necessarily? AFAIK madwifi is opensource and distributed by us. So, this bugreport is no more valid. Am I right? (In reply to comment #16) > Vlado, is this still necessarily? AFAIK madwifi is opensource and distributed > by us. So, this bugreport is no more valid. Am I right? The madwifi package is included in the 11.0 distribution [1]. I believe this bnc is invalid. [1] openSUSE 11.0 distribution (openSUSE:11.0) Marked as INVALID, described in comments above |