Mailinglist Archive: yast-devel (28 mails)

< Previous Next >
Re: [yast-devel] Direction of YaST Architecture?

On piatok 28 Január 2011 16:50:10 Arvin Schnell wrote:

in a recent telco the question about the direction of the YaST
architecture was raised.

In the pase a lot of things have been tried. E.g. integrate
different languages (Perl, Python, Ruby), try different build
systems (cmake), automatic generation of bindings for C/C++
libraries (libstorage) or simply use common technologies
(e.g. CIM). This is not necessarily bad but from my point of view
quite a few ideas are stuck halfway (Python integration) or are
simply of bad quality (generation of bindings). Even usage of
Perl seems to be considered to be no improvement.

But instead of removing failed approches we keep them and often
do not even look at better ways. As a result the YaST
architecture is on one hand more complex and confusing then
required and on the other hand lacks quality and features.

So now that we have minimal recourses to improve the YaST
Architecture we should concentrate on a few improvements instead
of dissipate our energies again.

So what seems desirable and feasible? Some ideas:

1) Replace YCP with some common language? With more that 100
modules this looks impossible.

I think this is a good and the only viable option if YaST code should survive
in long run.

The knowledge of YCP internals is slowly forgotten and the language is stalled
for some time now.

2) Allow a common language next to YCP? A good integration seems

I see this as step towards goal 1).

3) Improve YCP (at least fix bugs)? Do we want that?

What kind of bugs do you see in YCP? There is only a couple of them I'm aware
of and they can be easily workarounded. In this regard, I don't think it's
worth trying to fix them.

4) Better bindings of C/C++ libraries for YCP?

What's the goal of this option?

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
List Navigation