On Mon, 23 May 2016 19:00:36 +0200 Christian Boltz wrote:

Hello,

Am Montag, 23. Mai 2016, 07:43:59 CEST schrieb Goldwyn Rodrigues:

...

Apparmor has switched from perl to python (version 3.4). Most of the tools/libraries are written in python. All earlier perl modules have been deprecated. OTOH, yast is moving towards ruby deprecating python bindings, but still keeping the perl-bindings.

This leaves the fate of yast-apparmor in a bit unsupported state.

"a bit"? ;-)

2.8 was the last AppArmor version with perl-based tools, and they were not maintained too much ;-) (look at the perl code to understand the reason *eg*)

Since 2.9, we have the python-based tools with more readable code and less bugs.

...

I have tried rubypython, but it supports python version 2.7 only. Supporting version 3 and above is not in their agenda as yet. Another ruby module "python" is not actively developed/maintained.

So, I am asking for options on how we can take the development of yast-apparmor forward.

One of the options is to create dbus interface between servers_non_y2 and clients. But that would require another process running in the background for event loop. It comes with it the steps of cleaning up the process on a exit/kill etc.

Any other ideas? I am pushing for the comeback of python bindings if possible ;)

I'm thinking about implementing an alternative interface to aa-logprof and aa-genprof that uses JSON instead of user-readable text. (This is just an idea, no code for this exists yet.)

This would mean that YaST would start "aa-logprof --json", get the questions in JSON format (the exact format still needs to be defined), convert it into a matching YaST dialog, and send back the user response to aa-logprof.

It would also mean that you don't need to worry about the programming language because you just read and write JSON from/to a pipe, and that YaST gets all enhancements in aa-logprof automatically.

Does that sound like a good idea?

Note: "no code yet" also means that I can't promise a date when aa-logprof --json will be available ;-)

The YaST "profile editor" is a different story. I didn't think about a solution for it yet, but it should be possible to parse and convert a profile to JSON somehow. The interesting question is how we can teach YaST about allowed values without re-implementing everything in YaST.

BTW: Will you be at the openSUSE conference? If yes, we can talk there ;-)

Regards,

Christian Boltz

JSoN interface sounds good to me. I think it is good idea. As I said on IRC DBuS or CLI interface is good for yast. In general any stable format like XML, JSoN or YAML is good for YaST as it is easy to parse with ruby and easy to construct. BTW I will be at conference. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Dne 23.5.2016 v 20:43 Josef Reidinger napsal(a):

JSoN interface sounds good to me. I think it is good idea. As I said on IRC DBuS or CLI interface is good for yast.

I'd avoid DBus unless really needed, you need some background daemon to handle it and DBus might not be available.

In general any stable format like XML, JSoN or YAML is good for YaST as it is easy to parse with ruby and easy to construct.

All these formats are supported directly by Ruby stdlib, i.e. no need for external library. Personally I'd prefer JSON or YAML. XML is too heavyweight IMHO and tends to break easily (you need to maintain the schema), JSON or YAML are more "stable" and easier to parse/construct. -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org