Mailinglist Archive: opensuse-features (365 mails)

< Previous Next >
[openFATE 306116] Better lock handling in zypper
  • From: fate_noreply@xxxxxxx
  • Date: Tue, 2 Mar 2010 16:17:48 +0100 (CET)
  • Message-id: <feature-306116-16@xxxxxxxxxxxxxx>
Feature changed by: Ján Kupec (jkupec)
Feature #306116, revision 16
Title: Better lock handling in zypper

openSUSE-11.2: Rejected by Christoph Thiel (cthiel1)
reject date: 2009-07-16 18:04:38
reject reason: out of resources for 11.2.
Requester: Important
Projectmanager: Desirable

openSUSE-11.3: Evaluation
Requester: Important
Projectmanager: Desirable

Requested by: Marek Stopka (m4r3k)

Currently only two states in locking of packages are available (keep
package as is/do not care about package) but I think it would be much
more better to have a possibility lock only some parameters of
package... For example you have a 64bit machine, but you want keep some
package always in i586 version, but you still wanna version updates in
this case there should be a possibility to lock only this parameter. Of
course there is a lot of options what else can be locked, for example
version of package, meaning that you can't change package version, but
release number can change...

+ References:

#1: Federico Lucifredi (flucifredi) (2009-03-30 21:28:55)
I can see marginal value in an x86 vs x64 lock as 64 bits become more
upping to desirable.

#2: Ralph Ulrich (ulenrich) (2009-08-11 18:15:30)
I hate zyppers locking behavior. If you just want to reasure your
upgrades by a quick search, here a case study: I upgrade my openSUSE
factory. For it is much I do not use  verbose to keep oversight:
"zypper ref && zypper dup"
Now I am unsure about an arch change (a vlc library becomes i686 from
pm but I want to stick with, therefore on another console
I do:
"zypper se -s vlc"
Not possible - zypper search exits, it does not like the locked
database, why ?

#3: Ján Kupec (jkupec) (2009-08-12 11:53:05) (reply to #2)
This request is about package locks, not zypper process locks. However,
we are seeking to improve the inter-process locks as well, see e.g. , i'm not
sure if there's another FATE entry for this. And yes, we hate the
global zypp lock, too :O)

#4: Ján Kupec (jkupec) (2009-08-12 11:55:17) (reply to #3)
BTW, see here for a workaround (but use it with caution!!):

#5: Ralph Ulrich (ulenrich) (2009-08-12 13:25:30) (reply to #4)
Thank you for the hint.
Why not following suggestion as standard behavior of zypper:
1. for all normal users "export ZYPP_READONLY_HACK=1"
2. only make sure this isn't exported back to root through sudo

+ #6: Ján Kupec (jkupec) (2010-03-02 16:17:12)
+ There already is a possibility to lock by quite a range of parameters.
+ See 'man locks' or The locks
+ file contains queries editable by hand.
+ Zypper provides an interface (the *lock* commands) to manipulate just
+ simple package/type queries. If we want to extend this interface, we
+ need to define what exactly we want to achieve (which package
+ attributes to enable, etc). It is surely not reasonable to handle all
+ cases, and a simple generic interface is almost the same as editing the
+ locks file manually.
+ Where i see room for improvement (except for supporting additional
+ package attributes) is visualisation of the manually added special
+ queries in the 'locks' command (it should show them somehow, show the
+ results of specified query, etc).

openSUSE Feature:

< Previous Next >
This Thread