Re: YaST2 for Debian (aka nYaST)
Thanks for the overview Rumen!
> and Debian in architectural level. For example almost all configurations
> in YaST2 are made in directory sysconfig which is not LSB1/2 compatible,
Is it correct that the settings from /etc/sysconfig are written to the actual
application's config files in a second step?
Can settings in the /etc/sysconfig get out of sync with files under /etc?
Does the method involve leaving special "do not modify here" or "only modify
here or there" areas or magic comments in the config files that can
potentially confuse other tools or the user? Or will confuse yast if they are
What happens if config files are changed manually or with other tools? Does
yast still work on those, and does it preserve the formating or comments?
> and Prolog (for example) - there is a parser which translate this
> language to C.. For example you want a window and type
> window.open(parameters) and it translate it to GTK or curses or QT API
> in C.. Every checkbox, listbox, button and so on is described like
> this.. All places that needs name of file/directory is replaced by
> abstract global variable, which is described in separated file (.scp) -
> so it should be enough to edit these .scp to be compliant with Debian
> for every module and probably after many tests/debugs it will work..
If I understood correctly the modules do pretty much define the GUI and rely
on special parsers that refer to .scp files for global variables.
How does this scale to the debian project with different versions of packages,
possibly frequent updates, alternative packages? Would each require
maintaining/hacking and installing a new parser and special module? Or do
those .scp files describe what options and values can exist in the config