Re: YaST2 for Debian (aka nYaST)
Here is Rumen Krasstev's answer mistakenly didn't post on the list:
(and some additional notes)
> On чт, 2004-11-18 at 23:30, C. Gatzemeier wrote:
> > 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?
>
> Not always :((
> There is modules that have no simple receipt under other distributions...
> For example squid, shapers, etc.
>
> > Can settings in the /etc/sysconfig get out of sync with files under /etc?
>
> That is the main idea - if we redirect the .scp files Yast should use the
> correct config's so you can modify the config manually or via Yast..
I'm not sure if this is a pro or a con. Why does yast choose to write out
to /etc/sysconfig and not modify the real config file in the first place.
> > 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 removed?
>
> No, as I mentioned the Yast config files (in the sources - not in working
> station - that is before you make the binaries) are made only for this
> purpose - easily change the config
> path/filename/file_format...
I'm sorry, I was actually thinking about the config files of the programs you
want to configure...
> > 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?
>
> No SuSe config files are differ only slightly than normal ones - the file
> format of SuSe's samba config file is the same as the original smb.conf..
> But unfortunately not all modules are like this :-/
...it would be too bad if using yast would imply any restrictions on how you
can modify your config files on the system.
(Don't all /etc/sysconfig files have the same format?)
> > > 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.
>
> Indeed.. It is a little bit more complex but in general yes - you
> understood correctly..
>
> > 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 file?
>
> I'm trying to remove dependencies of the main YasT with his package
> manager, because Debian don't need it, thus this package manager is most
> terrible app that I ever seen :-/
> So my main task is to port Yast *without* it's shmency-fency package
> manager... We have apt-get for this and such nice tools like Synaptic -
> I think we don't need package manager in one place with Network servers
> or RAID for instance... as the same as Webmin - it is wonderful for so
> many administration tasks, why we should mess it with package
> management...
> Furthermore the SuSe package manager don't use .scp and .scr files
> directly - instead they do 1000 thinks that nobody understand (at least
> me)...
My question was rather about the pictured benefits of yast than about porting
or dependencies. ("There is no need to run if you are on the wrong route")
It's about whether the architecture pays attention to the need of a dynamic
project as debian, many app developers and package maintainers and different
public repositories that do not nessesarily all have to be at defined release
states.
IMHO ideally, for a contributer, an app writer or a package maintainer outside
of the config tool project, it should be basically enough say of which syntax
type the app's config file is and include an up-to-date description file of
the options the app can now take in its configuration file.
This means different/updated packages would not have to simoultaniously
require config tool hacking.
I guess it is questionable if stand-allone config tool project can keep up
with all the app development that is going on. Same with if app writers are
willing to continously maintain external config tools.
From this it seems a good config tool's architecture has to provide a way to
distributes the tasks well and easy.
While the last part was about the maintanance level my first set of questions
where about whether the config tool's architecture pays enough attention to
different use cases. Users configuring only with this tool, others using
other tools intermittently or doing changes by hand. Admins that run or write
own scripts. Package maintainers that need to provide config file update
scripts etc.
> Cheers
> Rumen
Regards,
Christian
Reply to: