On 05/24/2015 05:46 PM, robert.devanna@nospammail.net wrote:
On Sun, May 24, 2015, at 01:33 PM, Anton Aylward wrote:
looking at the Ruby code won't help you. The issue is the parameters that code works with which are in the packages.
Yep, figuring that out as I look around in here.
:-)
The only way you're going to deal with this is, as I said earlier, forget about yast altogether. ... The other approach, which I'm more inclined to take, is to ignore yast altogether.
Yeah, that's where I'm ending up.
:-)
Personally I can't see any good reason for a network config tool to be tied to specific firewall tools. At least without a simple option to turn that dependency off.
My mistake was initially assuming that since YaST is so 'hardwired in' to the distro that it'd be flexible enough for pretty standard, mainstream pkgs.
You might try using zypper or yast to black-list Susefirewall2
Already done.
Good.
I'll stick with the cmd line & config files approach and avoid gui assumptions that are just getting in the way.
:-)
I'm going to take a look at completely removing YaST. Not sure if that's even doable.
I'm not sure its doable but then I'm not sure its a "dependency". really its a wrapper. At the command line try # yast2 list *SOME* of those might be useful. Some things are just straight forward and it might be easier to use yast than to do the necessary figuring. MAYBE. In some instances. YMMV. It may also be useful to set up the basic config files which you then hand polish.
I'm sure not going to use a tool that's in the way of what I need done, causing more work rather than less.
That's the case here.
The best advice seems to be your " forget about yast altogether".
Specifically for networking, since it seems like wicked IS the future path for network setup here, I'll likely ignore all the compat: mode locations -- regardless of what YaST thinks we should be doing -- and just config manually into the wicked: locations.
And in general, there's nothing that I'm seeing YaST do that's much of an advantage to my usual "do it in shell" approach.
Yast is openSuse's main "value added" and the conversion from a dedicated but obscure language to Ruby was supposed to be a rationalization. I've been using Ruby (& RoR) for a number of years and as regular readers know support a parsimonious approach. I don't know if its architectural decisions or a side effect of the way the automated translation proceeded but the Ruby implementation of yast is far from transparent. Personally I think its tied to the original design and the way the original YCP was written. I've written a number of interpreters and meta-interpreters over the years and I know they can be incredibly powerful, very succinct and also quite transparent. http://opensuseadventures.blogspot.ca/2013/06/yast-is-being-rewritten-in-rub... https://news.opensuse.org/2013/10/10/coming-soon-opensuse-13-1-with-yast-in-...
wicked docs are still a challenge but the option to show the wicked XML config for an existing YaST-generated set up is a useful enough cheat for now.
Well, that kind of cheat is one use for yast :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org