[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: YaST2 for Debian (aka nYaST)



Hello Mario,
I'm doing big efforts last 6 months (since SuSe v 9.1 - I had
information for future gpl-ing of yast) to do this - port Yast2 for
Debian. I'm playing with the code these last months and I can give you
some advices - it's appear to be not so trivial task :-/
1. Yast2 don't even wish to compile under Debian - there are to many
dependencies, some of them not available to Debian, such as rpm 4.1.1
(in unstable it's 4.0.4) - rpm is a complex program and don't want to
compile too.. Dependencies between packages are so bad, that one can
compile/port only packages with documentations and some basic stuff.
I've some progress in this but I can't still compile the hole yast :(((
2. Even with successfully compilation it's impossible to use this
version of Yast in Debian - there are too many differences between SuSe
and Debian in architectural level. For example almost all configurations
in YaST2 are made in directory sysconfig which is not LSB1/2 compatible,
furthermore there are too many config files with custom names, like
timezone, firewall, etc. So in general using this version of Yast will
make your system unpredictable :(
3. Fortunatly the guys in SuSe made Yast (technologically) very mature -
it's totally modular and have 3 different independent levels (layers) -
representative (QT, curses and the new one GTK+), module (ex: firewall,
proxy, dns server, samba, etc.) and configuration files.. This is a long
story but i could tell you in general how it works - the modules are
written in abstract custom (4th level) language - something between C
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..
...
There is other problems, but I described only majors - the compilation
and the transformation of the .scp
So.. If somebody wants to helps me I can write him deep explanation how
it works (it is very complex and big system believe me)..
In this meaning I thing for this project a team of 3-4 people and 6-9
months probably will be enough...

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: