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

Re: YaST2 for Debian (aka nYaST)


On Fri, 2004-11-19 at 10:47 +0100, Rumen Krasstev wrote:
> On чт, 2004-11-18 at 18:26, Carlos Perello Marin wrote:
> > On Thu, 2004-11-18 at 16:35 +0200, Rumen Krasstev wrote:
> > 
> > [...]
> > 
> > > In this meaning I thing for this project a team of 3-4 people and 6-9
> > > months probably will be enough...
> > 
> > I think that with such resources you can give to GNOME System Tools and
> > the setup-tools backends the needed work to cover missing parts and that
> > will be available easily for any Linux distribution instead of just run
> > yast2 in Debian. Also, don't think you will get people that knows how to
> > improve Yast if they need to know about that complex system. If they
> > should learn that language you were talking about, add some extra months
> > to learn it...
> I agree, but the real problem is only the compatibility between the distributions - as I mentioned the architecture of YaST is 
> very modular - so probably (i hope) the efforts should be direct only to
> the .scr files (where is the configuration files/paths).. These files
> are simple and every person who knows what this module make (for example
> every admin knows what and where samba server does) can easily modify
> them to make compatible - for example Yast do all Samba settings in file
> /etc/sysconfig/samba and the file format is the same as the original
> smb.conf (I think), so only redirecting /etc/sysconfig/samba to
> /etc/samba/smb.conf will be enough :-))))) Of course there is files that
> have no analog in Debian but I don't think it will be so hard to make
> some simple scripts for transforming for example /etc/sysconfig/timezone
> ..

That's a quite easy example, but porting yast2 to debian will bring
bigger headaches than that :)

For putting some examples I could mention the network configuration or
the services that run at start time (quite similar to sysV, but not
equal), those also rely on their own tools that even don't let the users
modify the config files by hand, which IMHO is bad.

> The language that I mentioned is very simple - so this wouldn't be a
> problem to write new modules - the problem is to know how the particular
> daemon or technology works - for example the module bluetooth - you
> should know how the bluetooth stuff works and after that to make a nice
> looking interface (via YaST) to it...
> About the Gnome System Tools I don't agree - their major task is
> multiplaforming - every system that can start Gnome should be compatible
> with Gnome System Tools - that's why there is only few modules -
> data/time, user management, networks... More modules could make
> incompatibility in other architecture...

Sorry, I don't agree, as the GNOME System Tools maintainer, the worst
obstacle I find for doing new modules is the lack of time/manpower, as
for doing the tools portable, almost every UNIX has the same concepts in
system administration, and the GST can do a good job abstracting such
concepts (for example: the services tool configures successfully sysV,
bsd, filerc, rcng and gentoo init types, and the boot tool does the same
with lilo, grub and yaboot).


Reply to: