![](https://seccdn.libravatar.org/avatar/fd11770e2c72c423dd3e236b1ec2e094.jpg?s=120&d=mm&r=g)
Am 15.06.22 um 09:49 schrieb Ancor Gonzalez Sosa:
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.
That's good to hear. I was mainly replying to the more general discussion this had turned into, but as long as the container world and the package world can peacefully coexist I don't see an issue with this. Aaron