On Fri, Jun 21, 2013 at 10:40:29AM +0200, Josef Reidinger wrote: > On Thu, 20 Jun 2013 15:14:54 +0200 > Klaus Kaempf <[email protected]> wrote: > > > * Josef Reidinger <[email protected]> [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: [email protected] To contact the owner, e-mail: [email protected]
