Make zypper more flexible when multiple instances

[joantolo]

This is an idea for possible improvement.

Currently, most zypper commands require a lock to ensure access to a valid cache. The lock is used by the zypper instance most of the time it's alive, disallowing other zypper instances to execute other commands.

Can only use the lock when writing to the cache?

When a command has started and will write to cache, a new object PendingChanges or similar can be used to check potential conflicts when other zypper commands appear. As a first step when a new command conflicts pending changes, abort; a next step could improve that.

Does this make sense?

I would like to work on this, I'm trying to find in what part of the code the cache is read and where it is written.

Thanks!

[mlandres]

It's not a zypper issue. The lock is held by libzypp which is used by zypper, YAST and PK-updater applets.

The lock in fact does not ensure access to a valid cache, the cache must not be modified at runtime. Currently it's asserted that the owner of the lock can not be disturbed or interrupted by any other action until he finished. That's why the lock is exclusive. Fixing libzypp to safely support read/write locks is quite an effort. It was not written with concurrent access in mind.

We're working on a new GLIB based API for libzypp which may change this, but the work has just begun.