[Bug 551956] New: zypper al without explicit -type should derive the type from the name.
http://bugzilla.novell.com/show_bug.cgi?id=551956 Summary: zypper al without explicit -type should derive the type from the name. Classification: openSUSE Product: openSUSE 11.2 Version: RC 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers@forge.provo.novell.com ReportedBy: ma@novell.com QAContact: qa@suse.de Found By: --- # zypper al patch:yast2-samba-server # zypper ll # | Name | Type | Repository --+--------------------------+---------+----------- 1 | patch:yast2-samba-server | package | (any) This is unnecessarily wrong. If not type is explicitly given using --type, zypper can derive the correct type from the name. Class zypp:sat::Solvable::SplitIdent is intended to do this splitting. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 User ma@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=551956#c1 Michael Andres <ma@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |jkupec@novell.com --- Comment #1 from Michael Andres <ma@novell.com> 2009-11-02 17:14:18 MST --- As 'zypper rl' does not support -t at all, this notation is a convenient way to remove the correct lock again. The current 'zypper rl name' behavior is IMO also buggy. Zypper removes a lock for name even if it is not for kind package (which is what the commandline specifies). In fact one cannot remove specific non-package locks, as rl does not support -t. Supporting 'kind:name' notation would help, but -t should be added anyway. Fibonacci:~ # zypper ll # | Name | Type | Repository --+--------------------+---------+----------- 1 | yast2-samba-server | package | (any) 2 | yast2-samba-server | patch | (any) 3 | yast2-samba-server | pattern | (any) Fibonacci:~ # zypper rl yast2-samba-server Loading repository data... Reading installed packages... 1 lock has been successfully removed. Fibonacci:~ # zypper ll # | Name | Type | Repository --+--------------------+---------+----------- 1 | yast2-samba-server | package | (any) 2 | yast2-samba-server | patch | (any) - Initializing pool and target is most probably superfluous. - Zypper removed the pattern (last) lock. This is not what it was asked to do. @Jano: I sketched the suggested changes in branch 'ma-lock-changes'. Plaese have a look at them. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 User jkupec@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=551956#c2 Ján Kupec <jkupec@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW CC| |jkupec@novell.com, | |jreidinger@novell.com Info Provider|jkupec@novell.com | --- Comment #2 from Ján Kupec <jkupec@novell.com> 2009-11-03 07:56:41 MST --- (In reply to comment #1)
- Initializing pool and target is most probably superfluous.
it's needed by 'rl', since it uses PoolQuery to check how the newly removed lock is related with the other existing locks. The specified args can be e.g. just a subset of an existing lock query.
@Jano: I sketched the suggested changes in branch 'ma-lock-changes'. Plaese have a look at them.
I'll try to take a look today. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 User ma@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=551956#c3 --- Comment #3 from Michael Andres <ma@novell.com> 2009-11-03 08:39:52 MST --- (In reply to comment #2)
it's needed by 'rl', since it uses PoolQuery to check how the newly removed lock is related with the other existing locks. The specified args can be e.g. just a subset of an existing lock query.
But it does not need to execute the query, does it? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 User jkupec@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=551956#c4 --- Comment #4 from Ján Kupec <jkupec@novell.com> 2009-11-05 09:08:04 MST --- Michael, the changes in 'ma-lock-changes' look good. As for the code below "//hack to remove unique lock added by zypper", i talked to Josef about it and it turns out that it was intended to remove simple 'by-name' locks added by yast or zypper by first finding them in Locks. This was in order to prevent bothering users with confirmation dialogs. But you're right it won't work in some cases. I'd remove it, as you suggest, we'll see how it will behave. As for -t for rl, i agree it should be added. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 User jkupec@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=551956#c5 --- Comment #5 from Ján Kupec <jkupec@novell.com> 2009-11-05 09:10:44 MST --- c#3: IIRC it does (how else would you determine whether query1 shares a few packages with query2?). Josef? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 User jkupec@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=551956#c6 --- Comment #6 from Ján Kupec <jkupec@novell.com> 2009-11-05 09:38:58 MST --- I just confirmed with Josef the pool is needed when removing the locks because it compares the results of the lock queries to see whether they intersect or not or they are equal (in results). In case of problem it asks user how to proceed via callback. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 User ma@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=551956#c7 --- Comment #7 from Michael Andres <ma@novell.com> 2009-11-06 06:46:33 MST --- (In reply to comment #6)
I just confirmed with Josef the pool is needed when removing the locks because it compares the results of the lock queries to see whether they intersect or not or they are equal (in results). In case of problem it asks user how to proceed via callback.
I don't see why this is necessary. To queries 'foo*' and '*oo' may or may not produce the same result in a specific context. Anyway they are never equal. IMO zypper rl should remove exactly the query that zypper al would have added. And equal is NOT same result in current context, but same query args which is context independent (syntactically equal, PoolQuery::operator==). Class Locks attempt to adjust the package locks in the Pool is actually wrong, unless you can make sure this pool is not used to commit. On commit the pool would write out the locks as individual package locks, and not the original queries. Better use ResPool::setHardLockQueries. The pool will not just write out the right lockset then, it will also correctly adjust locks in case repos are added/removed from the pool, or new package locks are applied removed by the UI. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 User jreidinger@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=551956#c8 --- Comment #8 from Josef Reidinger <jreidinger@novell.com> 2009-11-06 07:07:02 MST --- Hi, few notes: planned zypper behavior is that if you want remove lock from package e.g. libzypp, you expect that after zypper rl libzypp is libzypp no longer locked. For this reason I check which locks lock libzypp, If that lock looks like zypper (which locks only one package) or automatic lock from Pool (so via libzypp added lock), then it is removed. But if this lock locks more packages, then it should ask user. so for example: zypper al *zypp zypper al lib* zypper rl libzypp # informs user that there is two locks which locks more then just libzypp Reason why I add same result of Pool query instead of syntactic equal, is updates. If we change syntactic of query, then zypper cannot remove locks which add old zypper. I understand problem in third paragraph. Reason is that I don't know that setHardLockQueries is implemented when I implement this part. So feel free to improve it. Just don't forget to support all options in locks file as some user use it quite often (like lock whole i586 and use pure x86_64 system via arch lock). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 User ma@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=551956#c9 Michael Andres <ma@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #9 from Michael Andres <ma@novell.com> 2009-11-06 07:49:26 MST --- (In reply to comment #8)
so for example: zypper al *zypp zypper al lib* zypper rl libzypp # informs user that there is two locks which locks more then just libzypp
I see. So it could make sense someday to have options for a 'fast' rl that checks for syntax only, and a more sophisticated one that loads the pool and does the content checks. I leave the target loading on. Applied the remaining fix for zypper-1.2.10. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=551956 http://bugzilla.novell.com/show_bug.cgi?id=551956#c10 Swamp Workflow Management <swamp@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard| |maint:released:11.2:32913 --- Comment #10 from Swamp Workflow Management <swamp@suse.com> 2010-05-06 15:05:03 UTC --- Update released for: PackageKit, PackageKit-debuginfo, PackageKit-debugsource, PackageKit-devel, PackageKit-doc, PackageKit-lang, libpackagekit-glib12, libpackagekit-glib12-debuginfo, libpackagekit-glib12-devel, libpackagekit-qt12, libpackagekit-qt12-debuginfo, libpackagekit-qt12-devel, libsatsolver, libsatsolver-debugsource, libsatsolver-demo, libsatsolver-demo-debuginfo, libsatsolver-devel, libsatsolver-devel-debuginfo, libzypp, libzypp-bindings, libzypp-debuginfo, libzypp-debugsource, libzypp-devel, perl-satsolver, perl-satsolver-debuginfo, perl-zypp, python-satsolver, python-satsolver-debuginfo, python-zypp, ruby-satsolver, ruby-satsolver-debuginfo, ruby-zypp, ruck, satsolver-tools, satsolver-tools-debuginfo, yast2-ncurses, yast2-ncurses-debuginfo, yast2-ncurses-debugsource, yast2-ncurses-devel, yast2-ncurses-pkg, yast2-ncurses-pkg-debuginfo, yast2-ncurses-pkg-debugsource, yast2-qt-pkg, yast2-qt-pkg-debuginfo, yast2-qt-pkg-debugsource, zypp-testsuite-tools, zypper, zypper-debuginfo, zypper-debugsource Products: openSUSE 11.2 (debug, i586, x86_64) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com