On 28/06/2019 03:45, Stasiek Michalski wrote:
Hi,
I want to make some changes to patterns, so users have more freedom to select the patterns that they want. Remove dependency on patterns that are visible in YaST Packager, hide a few patterns, split YaST patterns depending on DE, so only tools that are missing from DE are installed.
Let's look at the state of patterns visible on the YaST sidebar now (without recommends, best case scenario): * GNOME Desktop Environment (Basic) selects: X Window System, Minimal Base System, Minimal Appliance Base * GNOME Desktop Environment (Wayland) selects: GNOME Desktop Environment (Basic), GNOME Desktop Environment (X11), X Window System, Minimal Base System, Minimal Appliance Base * GNOME Desktop Environment (X11) selects: GNOME Desktop Environment (Basic), X Window System, Minimal Base System, Minimal Appliance Base * KDE Plasma 5 Desktop Base selects: X Window System, Minimal Base System, Minimal Appliance Base * KDE Applications and Plasma 5 Desktop selects: KDE Plasma 5 Desktop Base, X Window System, Minimal Base System, Minimal Appliance Base * XFCE Desktop Environment selects: X Window System, Minimal Base System, Minimal Appliance Base
As of the latest changes to the control files the above ones now also install enhanced_base because traditionally these desktops have had those packages in there default install. I did this via the system role though rather then recommending the pattern.
* LXDE Desktop Environment selects: X Window System, Minimal Base System, Minimal Appliance Base * LXQt Desktop Environment selects: X Window System, Minimal Base System, Minimal Appliance Base * Enlightenment selects: X Window System, Minimal Base System, Minimal Appliance Base * MATE Desktop Environment selects: X Window System, Minimal Base System, Minimal Appliance Base * Fonts selects: NAN * X Window System selects: Minimal Base System, Minimal Appliance Base * Multimedia selects: NAN * Office Software selects: NAN * Graphics selects: X Window System, Minimal Base System, Minimal Appliance Base * Games selects: X Window System, Minimal Base System, Minimal Appliance Base * Technical Writing selects: NAN * KDE PIM Suite selects: NAN * HPC Basic Compute Node selects: NAN * HPC Workload Manager selects: NAN * HPC modularized Libraries selects: HPC Basic Compute Node * File Server selects: Minimal Appliance Base * Network Administration selects: Minimal Appliance Base * Print Server selects: Minimal Appliance Base * Mail and News Server selects: Minimal Appliance Base * Web and LAMP Server selects: Minimal Appliance Base * Internet Gateway selects: Minimal Appliance Base * DHCP and DNS Server selects: Minimal Appliance Base * Directory Server (LDAP) selects: Minimal Appliance Base * Xen Virtual Machine Host Server selects: Minimal Appliance Base * KVM Host Server selects: Minimal Appliance Base * HPC Development Packages selects: HPC Basic Compute Node, HPC modularized Libraries, Base Development, C/C++ Development, Perl Development, Python 3 Development, Minimal Appliance Base * Base Development selects: Minimal Appliance Base * GNOME Development selects: X Window System, Base Development, C/C++ Development, Minimal Base System, Minimal Appliance Base * KDE Frameworks and Plasma Development selects: Base Development, C/C++ Development, Minimal Appliance Base * .NET Development selects: NAN * C/C++ Development selects: Base Development, Minimal Appliance Base * Tools for Packaging with Open Build Service selects: Minimal Appliance Base * RPM Build Environment selects: Minimal Appliance Base * Java Development selects: NAN * Linux Development selects: Base Development, Minimal Appliance Base * Perl Development selects: NAN * Python 3 Development selects: NAN * Qt 5 Development selects: Base Development, C/C++ Development, Minimal Appliance Base * Ruby Development selects: NAN * Web Development selects: Web and LAMP Server, Minimal Appliance Base * YaST Development selects: NAN * Tcl/Tk Development selects: NAN * Minimal Base System selects: Minimal Appliance Base * Enhanced Base System selects: Minimal Base System, Minimal Appliance Base * XEN Virtualization Host and tools selects: Xen Virtual Machine Host Server, Minimal Appliance Base * KVM Virtualization Host and tools selects: KVM Host Server, Minimal Appliance Base * AppArmor selects: Minimal Appliance Base * Console Tools selects: Minimal Base System, Enhanced Base System, Minimal Appliance Base * 32-Bit Runtime Environment selects: NAN * Laptop selects: Minimal Base System, Minimal Appliance Base * YaST System Administration selects: NAN * Software Management selects: NAN * Tests for the Update Stack selects: NAN * Minimal Appliance Base selects: NAN * Help and Support Documentation selects: Minimal Appliance Base * Documentation selects: NAN * Kubic Admin Node selects: Minimal Appliance Base, kubeadm Stack, Container Runtime for kubernetes clustered systems * Kubic Worker Node selects: Minimal Appliance Base, kubeadm Stack, Container Runtime for kubernetes clustered systems * kubeadm Stack selects: Minimal Appliance Base * Container Runtime for non-clustered systems selects: Minimal Appliance Base * Container Runtime for kubernetes clustered systems selects: Minimal Appliance Base * openSUSE MicroOS selects: NAN * Hardware Support selects: NAN * Apparmor Support selects: NAN * LDAP client selects: NAN * IMA/EVM Support selects: NAN * Support for Cloud selects: NAN
Patterns visibly selecting other patterns is a little limiting to the user that might want one pattern but not the other (which is either not possible, or possible if pattern is just recommended and the pattern is locked). The solution I want to implement as a replacement: * remove all the visible pattern dependencies (including recommends), so everything can be selected independently
To me this doesn't make sense, if pattern A requires or recommends pattern B it should be because the pattern A requires all the packages in B for example if the desktop patterns didn't require the X11 pattern they'd have to install those things them self, similarly with Base and Minimal Appliance base, then with most server patterns requiring the Minimal Appliance base, the idea is someone can just require that pattern and have everything needed for a functioning system. Then similarly with the base development pattern There is currently some weirdness though, I'll get to yast further down, but the _opt patterns all exist due to space limitations on the DVD, maybe it would be good if yast knew how to automatically merge these patterns or if we added a new "linkedto" or similar piece of metadata for it. Because once a system is installed and updated once these patterns shouldn't matter.
* hide "Minimal Appliance Base"/"Minimal Base System" pattern, so it's not selectable, considering it's the default base for most of openSUSE, so it has to be installed either way * hide "Base Development", it's already required by most development patterns
The list of tools in here is probably useful on its own without any other development patterns installed, make, git, autotools etc so i'd be inclined to leave it visible but I don't have a strong opinion.
* hide "GNOME Desktop Environment (Basic)", X11/Wayland split should be enough for selecting the base DE
Yep this is a SLE thing that doesn't really make sense for openSUSE (some SLE installs only have access to GNOME Desktop Environment (Basic))
* split desktop environments into desktop base and applications
This probably makes sense for Gnome / KDE / XFCE that have system roles that can select both, for others it will likely make sense to leave it as it is or have the desktop base recommend the applications, History has taught me that most users want atleast basic applications in there default install and will start to complain loudly if they are missing. Enlightenment for example would only have the "enlightenment" package in its desktop base pattern and everything else would be in apps originally we didn't ship any apps with it but lots of users complained so now we do.
That solution will obviously require changes to roles, which will need to depend on wider range of patterns, but that's fairly easy to do. After this change however, user will be free to go to Software in summary screen, disable patterns like Games or Office, without disabling recommends or removing GNOME patterns. I'm also in favour of making more `supplement` patterns, that expand the scope of visible patterns depending on other installed patterns (that schema is already largely in place, thankfully).
I agree with this approach.
Now the hardest part, DE specific YaST modules. Many of the functions provided by YaST are now handled by the desktops themselves, and on the desktop, YaST still tends to install quite a bunch of server software. As functionality provided by desktops vary quite a bit, deciding on what exactly needs to go into YaST will need to be decided on desktop-by-desktop basis. Right now I believe the only YaST modules that are required on every desktop are Package Manager (yast-packager module), Release Notes (yast-installation module), Firewall (yast-firewall module) and Bootloader (yast-bootloader module). I would argue as far as to say that in cases where there are not that many modules, YaST Control Center is not really required, considering modules are accessible from the desktop provided menus, but that might be too big of a change for now.
There are a couple of places in yast where we have started using supplements but I think that should probably be expanded to most things in the "Network Services" category, unless your weird like me and run a http server on your laptop many of these don't make sense to default desktop installs. I guess you could do similar with the Filesystem Snapshots, sudo and Alternatives even if they will probably end up on most default installs. I kinda like the idea of adding a "YaST Desktop" pattern for stuff like Printer / Scanner / Sound / Language and maybe some others that gets included in the desktop's system roles. Most of these things tend not to apply to servers (except print servers). I would tend to leave more things in the default install though, someone installing yast on a server probably means they want to use yast to configure it to some point, so having stuff like the services manager, kernel settings, system log and systemd journal available makes sense. You could convince me that this list could go into a "YaST Server" pattern or something similar because they make less sense on desktops. But everyone has these things installed so supplements won't really make sense for these.
Desktop discoverability of YaST modules will soon improve due to providing appstream add-on metainfo for every YaST module, which will enable easy installation of modules from the software centers like GNOME Software and KDE Discover. I have some more changes planned to improve desktop state of YaST, like providing WM_CLASS and appid based on desktop files, which will fix icon scaling and icon display in DEs, but this is not for this email ;)
There was also an idea to provide patterns with appstream metainfo on their own, label them as package groups in PackageKit and make them installable from software centers that way as well, but that's very much still early stages, considering it would require changes in quite a few stacks to work. LCP [Stasiek] https://lcp.world
-- 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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org