Mailinglist Archive: yast-devel (28 mails)

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

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.

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

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

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

Other suggestion?

Of course we already have a list of ideas (only few about the
architecture), see:

Discussion is opened.


Arvin Schnell, <aschnell@xxxxxxx>
Senior Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N├╝rnberg)
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
List Navigation