On Fri, Jun 21, 2013 at 10:40:29AM +0200, Josef Reidinger wrote:
On Thu, 20 Jun 2013 15:14:54 +0200 Klaus Kaempf <kkaempf@suse.de> wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jun 20. 2013 13:37]:
Idea is that installation should drive it.
Agreed.
SCR is implemented in way, that you must use SCR and SCR must be aware where it runs, so it is done on low level.
Exactly. Put all the 'knowledge' into SCR and shield SCR users from this.
And this is where I see problem. Let consider two main use cases for community developers who want to add new module to YaST or reuse part of YaST.
1) There is already config tool for qt and have library and I want to integrate it into YaST to get all benefits like three UIs, share with other parts of YaST, reuse code in other parts or use such configuration in add-on during install. ( we already use it e.g. for dbus calls, but I see there a much more opportunities )
So what I must do is to replace all system touching calls with SCR. For me it is really big obstacle as you must change almost complete program or have problem to reuse existing library. If you use high level call, then you can just said I need config library and run my GUI. And if it is in installation in add-on, then installation ensure that library and your client code is in place and call it in chroot, so you don't need any change.
Is there actually a way to prevent developers to "bypass" SCR and simply use Ruby file operations or modules to access the system? And we shouldn't forbid others from what we do ourself, see libzypp and libstorage. Both don't use SCR. Regards, Arvin -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org