On Tue, 24 May 2022, Johannes Meixner wrote:
Hello,
On 2022-05-24 13:35, Simon Lees wrote:
On 5/24/22 20:41, Johannes Meixner wrote:
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.
Sigh :-(
The more I learn about package dependencies the more I come to the conclusion that it could be impossible to use them to let the user choose what software is wanted or unwanted.
Perhaps only hard dependencies do actually work but weak dependencies are in the end a dead end?
Perhaps weak dependencies do not actually solve something but only mitigate/hide certain issues for average users while causing other problems for other users?
I think package dependences are not the correct tool to do decisions like this. In fact the only working option would be to Require every possible functionality that was enabled at build time which of course prevents you from selectively uninstalling parts that are not required by your specific system configuration. But unless you implement system configuration solely within the RPM framework and never edit, say, your pam configuration, but only ever configure by installing one of the N to-be provided pam-XYZ-config packages there's going to be situations where config and package dependences do not play together. So for the network manager example you'd have networkmanager require networkmanager-config, provide networkmanager-config-wifi and networkmanager-config-wired packages which in turn require networkmanager-wifi. And disallow manual editing of the configuration. A much better solution would be to ship configuration metadata for Yast (or any other system management tool) in the base networkmanager package so that tool can do the "feature" sub-package delection for you. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)