With this new ebuild, the unicorn_usb_eth and unicorn_pci_eth modules are built only if the new "eth" USE flag is set. This flag is complementary to the "usb" flag the ebuild already handles. This way, the user can avoid building unnecessary modules. The new ebuild also improves the postinst-message which incorrectly stated that the module names were unicorn_pci and unicorn_usb. The new ebuild gets the module names from the MODULE_NAMES variable. Reproducible: Always
Created attachment 105747 [details] bewan-adsl-0.9.3-r3.ebuild
Description of the new "eth" USE flag: eth - Build kernel modules for ethernet-based modems.
Is that important for you to remove eth modules? The way I see it, eth USE flag do not serve the users at all. For those who are unfortunate enough to need the eth modules, the typical scenario would be like this: - emerge bewan - google to see why their module is not included there - after 5 minutes they discover the new USE flag and reemerge the package I added usb to IUSE because it is global and such USE flags tend to be configured by users before emerging anything.
(In reply to comment #3) Well, the idea I had in mind is to have the new 'eth' local flag be active by default, so that the behaviour of the new ebuild remains the same as the current one. Users would at least have the option of turning it off if they want/need to (which is my case). Adding the 'eth' flag can spare some googling because of the following problem. If both modules are built (unicorn_pci_atm and unicorn_pci_eth), then unicorn_pci_eth will be loaded upon booting (I believe during udev's initialisation). If the user has an internal modem (PCI card) instead of ethernet, then unicorn_pci_atm would have to be loaded instead. The user will have to discover why pppd is not working, realise that that the wrong module is loaded, unload it, and load unicorn_pci_atm. More googling will be needed to learn about udev's blacklisting mechanism (to prevent the loading of unicorn_pci_eth).
I have a problem with the following line: use usb && use eth && MODULE_NAMES="${MODULE_NAMES} unicorn_usb_eth(extra:${USB_S})" USE flags should never be used for filtering; their scope is to enable/disable features. I myself I've used such constructions in the past (X and tk in rp-pppoe - they had to be enabled together if you wanted the GUI frontend) but I realised it is wrong. IMO is better to give hints in pkg_postinst than filtering Ethernet modules. Care to post some nice einfos?
> I realised it is wrong. Why? I don't get your point. I only see advantages in offering the user the possibility to choose. Anyway, I'll be posting soon a version without the eth flag, only informative einfos.
Because a feature (in this case, installation of a kernel module) should be controlled by (at most) one USE flag. Lets take the old rp-pppoe case and see it through: -X -tk : no GUI -X tk : no GUI X -tk : no GUI X tk : bingo! This is a classic example of flag abuse. By their nature, flags have 2 states, which means a tuple of 2 flags will have exactly 2^2 possible states. Since I do have only 2 possible states ("install a GUI frontend" or the opposite) I should have do it with only one flag.
Created attachment 106606 [details] New ebuild, no 'eth' flag, only more informative einfos This is the current bewan-adsl-0.9.3-r2.ebuild where the only change is more informative einfos in pkg_postinst()
(In reply to comment #7) > By their nature, flags have 2 states, > which means a tuple of 2 flags will have exactly 2^2 possible states. Since I > do have only 2 possible states ("install a GUI frontend" or the opposite) I > should have do it with only one flag. Note that in our case we do have all 4 possible combinations: unicorn_usb_eth unicorn_usb_atm unicorn_pci_eth unicorn_pci_atm All 4 modules listed above can be built from the sources provided by BeWAN. The 'usb' flag controls the bus type (whether PCI or USB), and the 'eth' flag would control the network interface type (whether Ethernet or ATM). The ebuild could have two variables, BUS_TYPE and IFACE_TYPE that would be set according to the 'usb' and 'eth' flags. But there is an alternative (I think of it only now). The 'atm' flag already exists in Portage. Instead of introducing the new 'eth' flag, we could reuse 'atm' to choose the network interface type (Ethernet / ATM).
The only way to make modules selectable by user is through USE_EXPAND flags, like in net-dialup/misdn case (see profiles/desc/misdn_cards.desc). Do you think is worth it?
(In reply to comment #10) > The only way to make modules selectable by user is through USE_EXPAND flags, > like in net-dialup/misdn case (see profiles/desc/misdn_cards.desc). > > Do you think is worth it? You are right, USE_EXPAND would be the cleanest way. But we don't have the time to do it do we :-) So I leave to your consideration the new ebuild (see Comment #8) which doesn't add new USE flags, it simply gives einfo on how to avoid the loading of unwanted modules. Note: even if the new ebuild is not accepted, the current one should be corrected, since the information it gives is wrong (incorrect module names).
Info messages has been added to the postinst in -r2 ebuild. Thanks!
