Re: YaST2 for Debian (aka nYaST)
On пт, 2004-11-19 at 19:19, C. Gatzemeier wrote:
> 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!
Danke (this is the only deutsch word that I know :-)))
> > > > 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.
As we have "Debian way" they have "SuSe way" :-))) (I don't like so much their way, but what can I do)
So, it's not YaST issue - it's SuSe one :-/ (for example they have /srv (from server I guess)
directory under root - a bit stupid for me)..
> > > 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...
That is the same - the logic is like that:
in the .scr for samba (for example) module there is harcoded VAR_PATH =
"/etc/sysconfig/samba" with described file format after that (the
brackets, the key=value, etc.) After the compilation of the module you
*cannot* change this values - YaST will look always for this file format
and this file path.. So you have full rights to equal the original
smb.conf (from fi.samba.org or from debian.org) with the YaST one, but
before release the binaries, I mean YaST have only few configuration
options during it's working (binary) state.. I hope I catch what you
mean and answer correctly :-))
>
> > > 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.
It depends of view - SuSe is for corporations, they don't want freedom, they want usability :-/
That's why GPL'ed YaST is wonderful, because we can change this :-)))
> (Don't all /etc/sysconfig files have the same format?)
No, there are exceptions, but in general they are very similar to the original, but still differs than the originals..
> > > > 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.
Indeed - I think that was the original idea of YaST, but during the
years, they mess up all the stuff :-/
Let me explain my view:
For me there are only few big differences between Linux distributions:
1. The tradition and general point of view - their "view" where they are
and where they are going to be.. (very importrant)
2. The package system (not so importrant - rpm/yum and deb/apt going
close more and more)
3. The *graphical* installer (importrant)
4. The main *graphical* configuration tool (importrant)
5. Other "issue inspired solutions" differences - init scripts, some
importrant servers (mail, web, proxy) or just services (firewall, system
monitors, etc) even kernel patches.. (importrant)
..
For me in points 1, 2 and 5 Debian is "unbeatable" :-)))
But thinking about Ian Murdock's Anaconda (look platform.progeny.com)
port we reach to one conclusion - Debian desperately needs nice looking
easy installer for the masses and similar main configuration tool.
Because these tasks are not trivial at all, SuSe and RedHat chose the
most mature variant - strong core system plus easy written modules -
mandatory in simple language - Anaconda - Python, Yast - their own
simple language.. So, it is the only solution that would works in the
future for such "dynamic" tools.. To have core system and some kind of
plug-in system - easy implementations for the potential contributors..
So, is it worth the efforts? For me - yes, definitely..
> 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.
Indeed, that is the idea..
> This means different/updated packages would not have to simoultaniously
> require config tool hacking.
That would be the ideal variant, but in real life nobody succeeded to do that completely...
> 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.
You catch the whole idea - that's it :-)))
> 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.
In SuSe world there is only one solution - YaST, in most cases it is enough that's why
good planned tool can solve almost all problems in price of liberty
(that is the M$ way too)...
All the problems that you mentioned is not actual to SuSe - they just
don't have community with contributors, maintainers, etc.. They solve
their problems as monocracy :-/ That means all the potential problems
that you mentioned is passed easily by SuSe, but would hit Debian
without delay...
Regards
Rumen
---
Rumen Krasstev - Object Builder Software Bulgaria
Sofia, 113 Tzarigradsko Shose, phone: +359 2 974 33 16
web: http://www.obs.bg, email: rkrastev@obs.bg, icq: 35447386
###I'm using only free or/and open source software###
Share the freedom - "Free Software Association - Bulgaria" http://www.fsa-bg.org
---
Reply to: