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 <mmeeks@novell.com>). 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.