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. 2) There is interesting part of YaST and you want to reuse without all machinery of YaST ( like studio want use it, parts reuse in WebYaST, reuse in chef etc. ) If you want to do it, you must install whole SCR machinery which is quite big (you need component system, you need few libraries, you need a lot of agents and its configuration, you need translation between various languages ). Also there is not many people that understand it. Usually this ends up with write it again from scratch and I consider it as our fail. If we use for files augeas and for running script direct calls, then it is easy to reuse it almost everywhere immediately.
My idea is that installation should drive it and top level module should do something like chroot.run TopLevel::Method...like chroot.run Network.write (complex_map)
This seems to add lots of complexity (and responsability) to individual modules.
Instead of
chroot.run Network.write(complex_map)
No it is not this way in all modules. Current work-flow is that you have part that makes proposals and that run out of chroot and then after user confirm it, you write such settings. So for me it should be handled by *installation* module modules.each { |mod| mod::Proposal() } show_gui() if (accepted) chroot("/mnt") do modules.each { |mod| mod::write_settings() } end end and in Network::Write can be Network::Write(map m) m[:network_card].each do |card| setup_card(card) end `rcnetwork restart` # or call System, or call directly Systemd or another module or Cheetah, it is up to you end So for simple modules you can use direct write or file edit, for more complex part you can use existing modules that helps you, but important is that module care about its own bussiness and need not care about layer that ensure writting in installation. I hope you see my POV, where I hope, that components should be simple and stand-alone so it can be easily reusable and we can easily reuse components from REST of world. It would be nice to have a lot of NIH modules or simple wrapper around "rest of the World" libraries. ( for me the perfect state is when there is configuration libraries from third party and we only have layer over it in YaST that coordinates relations between components and show GUI ). Josef
I'd rather see something like
# global 'chroot' call, done by installer SCR.init("/mnt") ... Network.write(complex_map)
and
module Network
# SCR init still needed if Network is run stand-alone # it's a no-op if SCR.init was called before SCR.init ... SCR.write ... end
Klaus
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org