Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] SCR usage statistics.
From: "Klaus Kaempf" <kkaempf@xxxxxxx>
Sent: Thursday, November 15, 2007 12:35 PM
To: "Michal Svec" <msvec@xxxxxxx>
Cc: "YaST" <yast-devel@xxxxxxxxxxxx>
Subject: Re: [yast-devel] SCR usage statistics.

* Michal Svec <msvec@xxxxxxx> [Nov 15. 2007 18:05]:

On Thu, 15 Nov 2007, Klaus Kaempf wrote:

> I scanned all files below /usr/share/YaST2/{modules,clients,include}
> grepping for "SCR::". Just to get statistical relevant data, not for
> complete coverage.
> The goal is to get relevant data for a SCR redesign to be implemented
> in parallel to the current SCR and have modules converted over time
> and shut down SCR is some distant future.

May be a dumb question, but which problems are we trying to fix?

I see sevaral problems

- Code cleanup / refactoring
SCR is not fully understood by developers (coding all kinds of
workarounds) and incomplete in some regards (developers parsing files
in ycp). This should be fixed.

- No / Inconsistent modeling
The pathes and data structures used in SCR effectively define a model.
There is no clear documentation nor consistency in this model. Should
we make the SCR model consistent or pick up an existing one (i.e. HAL
for hardware probing or CIM for everything)

- Reuse of existing code
For historical reasons (non-GPL license of YaST), SCR agents don't use
existing implementations for instrumentation. For Code11, we have the
requirement of 'friendly coexistance' with CIM instrumentation. A
resonable combination would be to replace agents with existing CIM
provider code.

- Separation of rights
Security and 'role based' considerations recommend to separate the
controller code (WFM in YaST) from the backend (SCR in YaST). The
controller code should run without root rights, the backend code should
assume root rights on demand (i.e. rpm -qa does not need root). This
requires a redesign of the SCR backend.

Also, are you suggesting a completely different SCR(-like) approach
or just "fixed" and more unified paths?

Thats what I'm trying to find out and get more input from developers.

The current thinking is to implement a completely different approach
while keeping the current SCR in place and migrate modules one-by-one.

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N├╝rnberg)


From experience, SCRs are just plain hard to use unless you are a rocket
scientist. Writing and consuming SCRs (or their potential replacement) should be a lot easier and more "fun".
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >