On Tue, 2022-05-24 at 21:05 +0930, Simon Lees wrote:
In this particular example think about a computer with a WiFi adapter but for some reason the user does not want to use WiFi or must not use WiFi (e.g. it may be forbidden to use WiFi on that computer because of whatever restrictions in the environment where that computer is used) - then it could become rather complicated for the user to somehow disable the automatism by some rather low-level hacking.
I don't this as a big problem. With my original idea, the user can install "system-requires-wifi", or "pattern-hardware-wifi" if you prefer. This package/pattern might be autoselected by Yast if Wifi hardware was detected. The user would undo this selection, and be done with it. (Yast would need some way to remember that the auto-selected pattern had be deselected by the user, to avoid re-selecting it again and again).
We can and do achieve the same results without patterns, for example firefox and chromium both have the following in there spec files "Provides: web_browser" this way patterns and other software can recommend or require "web_browser" and if chromium is already installed it won't also install firefox.
But which entity would require "wifi"? That was the point. The user needs some way to specify that she wants Wifi support, in a way that package management tools understand. Whether that's implemented with a pseudo-package, a pattern, or some other means doesn't really matter. Also, I don't think NetworkManager-wifi would provide "wifi". No single package would provide this feature. "wifi" would rather mean something like "if some package is installed that has a subpackage for wifi support, install the wifi subpackage, too". Therefore I think what we want to achieve here can't be achieved with abstract provides and requires. We need conditionals and complex dependencies.
In contrast if a WiFi pattern was used "in between" the automatism may only request to install this pattern but the user could simply "taboo" this one pattern instead of "tabooing" a list of various individual packages which may change over time.
It doesn't work like this as patterns only Require or Recommend other software they don't Provide anything, so all you achieve by "tabooing" a pattern is that pattern won't be installed, if I had a wifi pattern "tabooed" it would not prevent NetworkManager-Wifi from being installed. I do not know this part of rpm well enough to know if "NetworkMangager-Wifi" had a "Provides: Wifi" if you could then taboo or add a lock that prevents all providers of Wifi from being installed, but if that doesn't work currently it would be much more likely to be implementable then tabooing a pattern tabooing everything inside the pattern.
AFAICS you don't need to taboo anything. You'd just need to make sure "pattern-hardware-wifi" is not installed, _and_ that there's no mechanism to re-install it automatically once the user deselected it. Currently, when we install on a multipath system, Yast opens a pop-up saying "The system contains multipath hardware. Do you want to install multipath?". This happens only during initial installation. The same could be done for Wifi. Martin