Bug 116087

Summary: The rpm database must be closed while running YOU scripts
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Andreas Gruenbacher <agruen>
Component: YOUAssignee: Michael Andres <ma>
Status: RESOLVED FIXED QA Contact: Klaus Kämpf <kkaempf>
Severity: Blocker    
Priority: P5 - None CC: jsrain
Version: RC 1   
Target Milestone: ---   
Hardware: Other   
OS: All   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Andreas Gruenbacher 2005-09-09 11:15:13 UTC 
Michael explained to me that depending on the workflow, YaST may keep the RPM  
database locked while YOU is running a script from a patch. The script may try  
to install an RPM itself. If the RPM database is locked when the script tries  
to do that, the script will fail. 
 
Can YaST be changed so that the RPM database is always closed while running 
external scripts?
Comment 1 Michael Andres 2005-09-09 15:22:38 UTC 
The trivial soloution is to close the DB before ececuting the script.

BUT, 

YOU will not be aware of changes made to the rpmDB behind it's back. It would
not be that hard for the packagemanager to watch and reload the DB, like it is
done after comitting packages.

But AFAIK YOU is not prepared for re-evaluating it's decisions, if scripts
install additional packages which may introduce new dependencies.


At his point it bites us too, that we install with '--force --nodeps', because
this is done in the assumption, that our dependency resoloution and package
ordering  is correct and we have the same ammount of control as RPM has, if we
install packages. 

Due to '--force --nodeps' YOU will not even recognize any problem caused by the 
installation of new packages. 


But even if we'd recognize the trouble, there's no  save way out of it. That's
why RPM leaves the DB locked while executing scripts.

I consider it dangerous. You want me to unlock the DB?
Comment 2 Andreas Gruenbacher 2005-09-09 15:36:49 UTC 
The kernel update tool won't introduce additional dependencies that YOU would  
have to worry about, and it does proper RPM dependency checking itself. I vote  
for ignoring this hypothetical future problem for now.  
   
> But even if we'd recognize the trouble, there's no  save way out of it.   
> That's why RPM leaves the DB locked while executing scripts.  
  
I was told it has the DB locked only sometimes? Anyway, unnecessarily limiting  
otherwise reasonable things in scripts because YOU cannot perfectly ensure 
consistency sounds like a Bad Idea to me.
Comment 3 Michael Andres 2005-09-09 15:53:10 UTC 
- It's not a matter of the kernel update tool. If we allow installing rpms by
patch scripts, every script is able to do it.

- I don't know, if it is 'unnecessarily limiting reasonable things'. YOU is
expected to perform transactions and eshure consistency, IMO. 

- Yes, the DB is locked only sometimes - on may consider this a bug ;)


What we will get fast is not a feature, it's a hack. I simply want everybody
being aware of this, and aj to confirm it's OK.
Comment 4 Andreas Gruenbacher 2005-09-09 16:05:11 UTC 
If YOU did what we need, there wouldn't be a need for all this magic in the    
first place. Unfortunately it doesn't, so we need to work around it. YOU will  
not be where we need it before SLES10 at least, which is way too late. (We 
will also need a solution for SLES9 soon.)
Comment 5 Michael Andres 2005-09-09 16:08:59 UTC 
Added mir and jsrain to CC. We should care about this in ZYPP.
Comment 6 Andreas Gruenbacher 2005-09-09 16:14:01 UTC 
The plan for zypp is to have the package manager do what the kernel upgrade 
tool does now. There are a few open issues, but we'll hopefully find solutions 
for them as well.
Comment 7 Michael Andres 2005-09-09 16:40:43 UTC 
I didn't mean the kernel upgrade tool, but installation of rpms from within a 
patch script in general.

Fixed in yast2-packagemanager-2.12.19