On 6/15/22 02:51, Aaron Puchert wrote:
Am 14.06.22 um 10:55 schrieb Richard Brown:
[...]
Containerising YaST enables us to have as few of those language stacks as possible in the base and lets us ensure we only ship YaST with a configuration we know YaST was built to work with.
In my view this encourages bad habits: if you can't pin dependencies you have to read the documentation and rely on documented behavior only. What often happens (and is the reason for pinning) is that developers rely on undocumented behavior that breaks in future versions (could even break with recompilation) and perhaps doesn't even work reliably.
Compiling or running software against different stacks often uncovers real issues. In my area we regularly use multiple compilers precisely because they usually don't all have the same quirks.
If some software needs precisely defined dependencies, it's likely just very brittle and the bugs it has may just not materialize under some limited circumstances that maybe even a container can't reliably reproduce. (And even if, how would you know? Testing isn't exhaustive.)
Let me reiterate something: the containerized YaST is only a cherry-on-top of the regular YaST offering. We will still develop and ship YaST in its current form, fully integrated into the system. The very same code-base of YaST runs currently in SLES-15-SP4, Leap 15.4 (both including Ruby 2.5) and Tumbleweed (Ruby 3.1). That code-base has been adapted to all the Ruby versions (and other libraries) that have passed through Tumbleweed since the 15.4 release of Leap (basically every single major versions of Ruby from 2.5 to 3.1). This is not a way to take shortcuts in the YaST development nor to reduce the list of scenarios in which we care about integration. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions