I plan to submit this. Feel free to provide feedback before I do it.
Title: Almost two years of YaST News
Subtitle: Recent changes and future plans at YaSTland
YaST, the flagship installer and configuration tool of openSUSE is in
constant development. Just as its unattended companion AutoYaST.
Although the YaST Team at SUSE tries to communicate progress as often as
possible in the YaST Blog, it has been almost two years since we
presented the "Top 25 New Features in (Auto)YaST" at openSUSE Conference
2020. So it's time for another live update!
We will recap the main changes and new features that are already
integrated into openSUSE Tumbleweed and that will be included at
openSUSE Leap 15.4, to be released just a couple of days after the talk.
We will also take a look to some ideas for future development... and we
really need the feedback of the whole openSUSE community for that. So
please join us and speak up!
Ancor González Sosa
YaST Team at SUSE Software Solutions
I did some research about YaST and containers and here is my summary what I found.
But at first lets start with two IMPORTANT DISCLAIMERS:
1. This is still just a research or proof of concept project, we might or might not
use this approach in the future, i.e. no promises for anything!
2. If you want to test this approach then it is highly recommended to use a testing
virtual machine, do NOT use it in production systems, it is still an experiment!
OK, let's start with the reasons why to have YaST in a container.
As you probably know YaST has quite a big dependency tree and that makes it difficult
to use it a really minimal system. It needs Ruby, Perl, libyui, lots of other
libraries and tools. And all of that might mess up your fine tuned minimal system.
On the other hand a container has all dependencies hidden inside, from the outside
it actually looks like one big binary blob. Additionally it can be very easily
removed from the system if it is not needed anymore.
Another reason might be using different versions of libraries or languages than
shipped in the product. In theory we could use Ruby 3.1 in the container although
SLES would be still shipped with the old Ruby 2.5 for compatibility reasons.
Another interesting feature could be cross distribution ability. For example you
could run the powerful YaST partitioner in a container on an Ubuntu or Debian system.
Nice, isn't it? :-o
Today I found one more interesting use case: disaster recovery. First I removed
zypper + libzypp from the system and I was able to install it back using YaST
package manager in a container. Then I even removed rpm (!) itself and I was still
able to install it back to the system via the YaST container!
Of course, this requires that you have already installed docker or podman and they
work properly. ;-)
Of course, running in a container needs some small changes in YaST. Unfortunately
you cannot take the existing modules and expect everything will just work.
So far I have adapted these YaST clients:
"repositories" - the repository manager (the GPG key manager which can be started
from it works as well)
"sw_single" - the package manager
"scc - registration module, designed for SLES but you can actually also register
openSUSE Leap (so you can later migrate it to SLES automatically)
I built a small package "yast-in-container" . It is just a small shell script
which does not depend on YaST at all. It only requires podman or docker to be
installed (and running, in case of docker). See the README.md file  for details
how to install it.
It provides two commands, "yast2_container" and "yast_container" which work the same
way as the original "yast2" and "yast" commands. You need to be logged in as
"root" user to use them.
The script downloads the container image  from OBS and runs the specified
client (see above) from the container.
The prototype works in Leap 15.4 or SLES15-SP4. It should work in older versions
(15.3 or SP3), but that's untested and makes it even more "dangerous" to use
as the container is based on openSUSE Leap 15.4.
It would be nice to get some feedback about this idea or about using the prototype.
For more details see the README.md file .
SUSE LINUX, s.r.o.
18600 Praha 8
upstream parted accepted several new patches from SUSE and can
now print and set the "Partition Type GUID" on GPT. The changes
are already included in openSUSE Factory. So if needed it would
be easy to support all the GUIDs needed for the Discoverable
Partitions Specification .
Two possible implementation in libstorage-ng look obvious:
1. Extend the existing list of IDs:
+ No additional interface
+ Good names in commit messages
2. Add extra interface to directly deal with GUIDs:
+ More flexible
Arvin Schnell, <aschnell(a)suse.com>
Senior Software Engineer, Research & Development
SUSE Software Solutions Germany GmbH
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald,
JFYI, this might be interesting for the community or developers,
we added translation support for Qt Designer files to YaST/libyui.
This includes support for extracting the widget labels to POT file
and processing them via Gettext in Qt when loading the *.ui files
These PRs might be interesting for you if you want to use Gettext
translations in a Qt application designed with Qt Designer.
Thanks to Stefan (HuHa) for the libyui part!
SUSE LINUX, s.r.o.
18600 Praha 8
As you all know, the YaST team is lately involved in many projects not
limited to YaST itself.
So it's time to take a look to how things are moving on:
- Recent changes for YaST (just in time for Leap 15.4)
- Containerizing YaST to make it useful in container-based environments
like openSUSE Micro.
- Evolution of D-Installer
Check the whole report at
Ancor González Sosa
YaST Team at SUSE Linux GmbH