https://bugzilla.novell.com/show_bug.cgi?id=255745
sh@novell.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
Info Provider|sh@novell.com |
------- Comment #7 from sh@novell.com 2007-03-19 09:24 MST -------
That seems to be the behaviour of that new yast2-control-center-gnome (which is
maintained by Michael Meeks ).
I suppose this is intentional.
For yast2-control-center-qt we had discussed that several times: Do we want to
lock all of YaST2 as long as any module is open? Our conclusion had always been
that we don't want that. I would suggest that the new
yast2-control-center-gnome behaves similarly.
There are situations where the user can shoot himself into his foot if he has
multiple YaST2 modules running at the same time, yes. For example, the
sysconfig editor is a very generic tool that might change all files below
/etc/sysconfig; most other YaST2 configuration modules write to one or more
files below /etc/sysconfig, too. So if you have the sysconfig editor open and
edit some network settings there and open the network module at the same time,
the module that writes its settings last will win (and changes made in the
other will get lost).
Such is life.
But then, this is no different from using several other tools in parallel. You
can choose to edit any /etc/sysconfig file with "vi" while any other
configuration tool (YaST2 or other) changes the same file. Worse, multiple
users might try to configure the same machine at the same time; the one who
saves his changes last will win.
This is something all configuration tools on a Linux system have in common. But
then, this is a byproduct of having all configuration variables in text files
-- which OTOH is one major feature of Unix/Linux systems: You don't need any
sophisticated tools to change anything; simply use an editor. Or, if you
prefer, use a higher-level tool such as the YaST2 sysconfig editor (only
slightly more sophisticated to using "vi" for /etc/sysconfig files) or a
dedicated YaST2 module that configures any specific subsystem.
The tools we provide do not substitute synchronizing and organizing system
management tasks. The people (!) who manage a system have to talk to each other
to agree who does what (and when) and who is responsible for what.
The same applies to one single person. Most users don't start a bunch of YaST2
modules just for fun; generally, they tend to want one task done like configure
the network or install software. The latter task OTOH is so common that at
times it does make sense to leave that module open just in case you need to
install even more packages (during which time the RPM data base is locked, but
that would only hurt for using "rpm" on the command line). Just think of a
developer who gradually tries to figure out what packages to install to satisfy
whatever some "configure" script wants. OTOH at the same time that user might
find out that he has to configure some system service (e.g. ntp to make "make"
shut up about time stamps in the future with files residing on NFS).
Bottom line: It makes a lot more sense to allow multiple YaST2 modules running
at the same time than to enforce to have only one running. And the latter
wouldn't do any good with multiple users trying the same anyway.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.