Hi Stefan, thanks for bringing this up. The main problem I see with your approach is that we end up with that wrapper at the end of the day. So we would have libstorage <-> wrapper <-> ruby. Depending on the complexety of the wrapper it means more documentation, more difficult debugging and more work for new features. I my proof of concept redesign there is also a wrapper but at a different level: It provides the C++ interface of the existing libstorage for the redesign libstorage. That way the ruby code can stay as it is while switching the underlying library and then the ruby code can be converted piece by piece. In the end the wrapper (and the target map) will be obsolete. In the proof of concept I have already show that such a wrapper is possible (in Febuary it was able to install the most simple system) and that the interface of the new libstorage can be used at the same time from ruby. I admit that since the data structure of the redesign libstorage is very different from the old one the interface wrapper is not simple but tricky and implementing every corner-case will be difficult. So including the wrapper in a maintained release it not what I recommend. ciao Arvin -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org