Stanislav Visnovsky wrote:

Dňa Ut 12. Jún 2007 16:38 Jan Kupec napísal:

...

Where we don't want a zypp lock? Where we need read access only in general. In particular:

- listing known repositories - search (all kinds - listing available updates falls into this category)

You need to make sure that the parsers are not hard at work at that point.

The function to check for an existing zypp lock could be used for that cases, see below.

...

Also, some function for checking whether other app is having the lock would be nice for use even if we don't need the lock. Having that, e.g zypper search could show a warning that the search result can be inaccurate because of another app manipulating zypp data.

-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Dňa Št 14. Jún 2007 12:51 Jan Kupec napísal:

Stanislav Visnovsky wrote:

...

Dňa Ut 12. Jún 2007 16:38 Jan Kupec napísal:

...

Where we don't want a zypp lock? Where we need read access only in general. In particular:

- listing known repositories - search (all kinds - listing available updates falls into this category) - other queries like zypper info, zypper patch-info, etc - (other cases?)

This list also applies to read access for non-root users. That means /etc/zypp/repo.d/* and /var/lib/cache/zypp.db must be readable by non-roots. (I can't think of more.)

/etc/zypp/repo.d/* contains passwords, so we can either store passwords elsewhere or disallow access to that directory for non-root.

Please let's decide this now as this affects zypper (it does not affect yast, since it requires root anyway). The options:

1. we will always require root for 10.3 2. make /etc/zypp/repos.d world-readable and solve the passwords issue later 3. make /etc/zypp/repos.d world-readable and store passwrods in a separate file accessible by root only (e.g. /etc/zypp/repos.d/passwd)

Option 3) sounds good to me. Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Tuesday 12 June 2007 17:08, Klaus Kaempf wrote:

* Jan Kupec [Jun 12. 2007 16:38]:

...

Where we don't want a zypp lock?

We should remove the global zypp lock alltogether and move to more fine grained locks based on state changes.

Currently I see the following state changes - repo added / removed - cache changed (due to repo add/remove/update) - system changed (transaction in progress)

For example, a transaction must only locks those repositories which are part of the transaction. But I don't see the need to lock the metadata cache during a package transaction.

Maybe I'm too optimistic here ...

Yes, as sqlite manages most of the locking itself it will be easier to remove the lock. But I don't think it is a 10.3 goal. -- Duncan Mac-Vicar Prett   Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org