On 5/25/22 20:09, Martin Wilck wrote:
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.
One option would be the Desktop patterns, another could be the installer detecting a wifi adapter and auto selecting it or both.
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".
If we are moving away from a world with Wicked then NetworkManager-wifi might be the only package that provides wifi, although I believe we still have connman in the repos which could also provide wifi and as long as one of those two packages are installed the user should wind up with working wifi.
Therefore I think what we want to achieve here can't be achieved with abstract provides and requires. We need conditionals and complex dependencies.
Possibly it depends how far we want to go and how much we really care about the migration for people with no-recommends, which ends up being I don't want almost all recommends.
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.
Yep the question is whether its more sensible to do that logic by installing the NetworkManager-Wifi package, a meta package or a pattern, the advantage of the later two is we wouldn't need to update a hard coded value in the installer whenever we change the package. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B