On Wed, 27 Apr 2011, Cristian Morales Vega wrote:
2011/4/27 Richard Guenther <rguenther@suse.de>:
On Wed, 27 Apr 2011, Michael Schroeder wrote:
On Tue, Apr 26, 2011 at 10:13:48PM +0200, Cristian Morales Vega wrote:
2011/4/26 Ladislav Slezak <lslezak@suse.cz>:
Dne 26.4.2011 11:46, Michael Schroeder napsal(a):
The collection mechanism was added for the selinux folks. I don't think you should use it at the moment. (It also only helps you if you use one big transaction to install all rpms. I think you should rather fix gtk-update-icon-cache to support incremental updates.)
So when installing such packages using zypper or YaST the collections would not help as libzypp installs packages one by one (just a single package in every RPM transaction).
So another argument to change the default for commit.downloadMode from DownloadAsNeeded to DownloadInHeaps? ;-)
Actually the default has already changed, I think.
IIRC the only argument for maintaining DownloadAsNeeded was hard drive space considerations.
Otherwise the only way to get the wanted behavior would be at ZYpp level. Last time I looked at it "update-scripts" were an ugly solution for this, I'm not even sure if it was possible to use it for this purpose at all.
Zypp still calls 'rpm' for each transaction step for various reasons. One of them is that you can continue with the transaction if a step fails.
Which is a bug rather than a feature ;)
I'm far from an RPM expert. But indeed, if "continue with as much packages as you can" is the wanted behavior when a package fails... probably that should be the behavior at RPM level? Having a behavior at RPM level and then change it at ZYpp level seems weird.
Btw, the usual answer I got was not the above but that if an rpm transaction fails there is no way to roll it back. That's true, but of course the same is true for a failed single-rpm transaction. I suppose the real issue is that zypp doesn't know how to build a set of rpms that form (minimal) completable transactions, and feeding all rpms of a "zypp transaction" to rpm may cause memory usage issues (another answer I got) or in case of a transaction failure a system status that is harder to repair manually. Of course we know that you can get a broken system trivially by doing partial transactions that render rpm itself useless (like updating liblzma ...). Something rpm easily avoids ... Thus, the answer in the end is: "never change a (working) system" (with bugs you all know). Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org