[zypp-devel] very weird zypper behaviour
Hi, the live cds are broken since today and I debugged it a bit and the zypper behaviour below kiwi is _very_ weird. I patched kiwi to call --debug-solver and I get e.g. <addReq name="libltdl = 3"/> in the zypper command line it was zypper libltdl-3 Who splits the package name? Interestingly enough not all package names. But also "ghostscript = x11" is installed. Greetings, Stephan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Am Donnerstag, 17. April 2008 schrieb Stephan Kulow:
Hi,
the live cds are broken since today and I debugged it a bit and the zypper behaviour below kiwi is _very_ weird.
I patched kiwi to call --debug-solver and I get e.g. <addReq name="libltdl = 3"/>
Yeah, 100% reproducible: zypper --root /tmp/t sa <beta1-DVD> beta1 zypper --root /tmp/t in --debug-solver libltdl-3 generates: <trial> <showpool all="yes"/> <addRequire name="libltdl = 3"/> </trial> Greetings, Stephan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Stephan Kulow
Am Donnerstag, 17. April 2008 schrieb Stephan Kulow:
Hi,
the live cds are broken since today and I debugged it a bit and the zypper behaviour below kiwi is _very_ weird.
I patched kiwi to call --debug-solver and I get e.g. <addReq name="libltdl = 3"/>
Yeah, 100% reproducible: zypper --root /tmp/t sa <beta1-DVD> beta1 zypper --root /tmp/t in --debug-solver libltdl-3
generates: <trial> <showpool all="yes"/> <addRequire name="libltdl = 3"/> </trial>
Somewhat funny coincidence. rpm5 suffers from a similar problem: http://rpm5.org/community/rpm-devel/2529.html Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stephan Kulow wrote:
Hi,
the live cds are broken since today and I debugged it a bit and the zypper behaviour below kiwi is _very_ weird.
I patched kiwi to call --debug-solver and I get e.g. <addReq name="libltdl = 3"/>
in the zypper command line it was zypper libltdl-3
Who splits the package name? Interestingly enough not all package names. But also "ghostscript = x11" is installed.
Hm, this was supposed to be a nice heuristic, now i see it has some flaws :O( This was done in order to be able to install like this: $ zypper install foo-package-1-2.0.3-5 The workflow: for each '-' found in the string { replace '-' with '=' check if there is something wich provides such capability if there is something { use this; break } } obviously this will not work for libdtl-3 as there obviously are providers of libdtl = 3. Bad idea :O( I can remove the code doing this in a minute, but i'd appreciate suggestions how to do this 'zypper install zypper-0.11.1'.... Sorry for this. Cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
I can remove the code doing this in a minute, but i'd appreciate suggestions how to do this 'zypper install zypper-0.11.1'....
Reading the thread and you last sentence, i just thought on zypper install zypper@0.11.1 "@" is commonly used and it felt "natural" here ... Just my 2 cent ... Best regards Jan-Simon -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Jan-Simon Möller wrote:
I can remove the code doing this in a minute, but i'd appreciate suggestions how to do this 'zypper install zypper-0.11.1'....
Reading the thread and you last sentence, i just thought on
zypper install zypper@0.11.1
"@" is commonly used and it felt "natural" here ...
Yes, you can already use '=' (zypper install zypper=0.11.1), no problem with that, but there were specific requests to be able to use also dash instead of the '=' (since the packages with version are often described like that). Also, rug is doing it somehow (curious :O) with the dash, and we should be compatible with rug as much as possible. I disabled the code for now... in case anybody is interested, here it is: // try to find foo-bar-1.2.3-2 if (!by_capability && str.find('-') != string::npos) { string::size_type pos = 0; while ((pos = str.find('-', pos)) != string::npos) { string trythis = str; trythis.replace(pos, 1, 1, '='); DBG << "trying: " << trythis << endl; Capability cap = safe_parse_cap (zypper, trythis, kind); sat::WhatProvides q(cap); if (!q.empty()) { str = trythis; by_capability = true; DBG << str << "might be what we wanted" << endl; break; } ++pos; } } jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Am Donnerstag, 17. April 2008 schrieb Jano Kupec:
Stephan Kulow wrote:
Hi,
the live cds are broken since today and I debugged it a bit and the zypper behaviour below kiwi is _very_ weird.
I patched kiwi to call --debug-solver and I get e.g. <addReq name="libltdl = 3"/>
in the zypper command line it was zypper libltdl-3
Who splits the package name? Interestingly enough not all package names. But also "ghostscript = x11" is installed.
Hm, this was supposed to be a nice heuristic, now i see it has some flaws :O( This was done in order to be able to install like this: $ zypper install foo-package-1-2.0.3-5
The workflow: for each '-' found in the string { replace '-' with '=' check if there is something wich provides such capability if there is something { use this; break } }
obviously this will not work for libdtl-3 as there obviously are providers of libdtl = 3. Bad idea :O(
Why not check first if something provides libltdl-3 ? BTW: I noticed this only because the live cds were enlarged by as little as 70MB due to kernel-source.rpm providing "linux". Greetings, Stephan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stephan Kulow wrote:
Am Donnerstag, 17. April 2008 schrieb Jano Kupec:
Stephan Kulow wrote:
Hi,
the live cds are broken since today and I debugged it a bit and the zypper behaviour below kiwi is _very_ weird.
I patched kiwi to call --debug-solver and I get e.g. <addReq name="libltdl = 3"/>
in the zypper command line it was zypper libltdl-3
Who splits the package name? Interestingly enough not all package names. But also "ghostscript = x11" is installed. Hm, this was supposed to be a nice heuristic, now i see it has some flaws :O( This was done in order to be able to install like this: $ zypper install foo-package-1-2.0.3-5
The workflow: for each '-' found in the string { replace '-' with '=' check if there is something wich provides such capability if there is something { use this; break } }
obviously this will not work for libdtl-3 as there obviously are providers of libdtl = 3. Bad idea :O(
Why not check first if something provides libltdl-3 ? BTW: I noticed this only because the live cds were enlarged by as little as 70MB due to kernel-source.rpm providing "linux".
Yes, this works, plus (if nothing provides the original string) i start to replace dashes for '=' from right to left. I can't think of any other way how it could fail now, but still if you want to install by name only, you can force it with --name option (although this way zypper chooses the version to install, not the solver). But still, isn't this a bug? $ zypper what-provides ghostscript=x11 Reading installed packages... S | Repository | Type | Name | Version | Arch --+------------+---------+---------------------+-----------+------- i | @System | package | ghostscript-library | 8.15.4-17 | x86_64 v | factory | package | ghostscript-library | 8.62-4 | x86_64 v | factory | package | ghostscript-library | 8.62-4 | i586 There should be no providers of ghostscript=x11 or? And similarly for libldtl=3. jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Am Sonntag, 20. April 2008 schrieb Jano Kupec:
Stephan Kulow wrote:
Am Donnerstag, 17. April 2008 schrieb Jano Kupec:
Stephan Kulow wrote:
Hi,
the live cds are broken since today and I debugged it a bit and the zypper behaviour below kiwi is _very_ weird.
I patched kiwi to call --debug-solver and I get e.g. <addReq name="libltdl = 3"/>
in the zypper command line it was zypper libltdl-3
Who splits the package name? Interestingly enough not all package names. But also "ghostscript = x11" is installed.
Hm, this was supposed to be a nice heuristic, now i see it has some flaws
:O( This was done in order to be able to install like this:
$ zypper install foo-package-1-2.0.3-5
The workflow: for each '-' found in the string { replace '-' with '=' check if there is something wich provides such capability if there is something { use this; break } }
obviously this will not work for libdtl-3 as there obviously are providers of libdtl = 3. Bad idea :O(
Why not check first if something provides libltdl-3 ? BTW: I noticed this only because the live cds were enlarged by as little as 70MB due to kernel-source.rpm providing "linux".
Yes, this works, plus (if nothing provides the original string) i start to replace dashes for '=' from right to left. I can't think of any other way how it could fail now, but still if you want to install by name only, you can force it with --name option (although this way zypper chooses the version to install, not the solver).
But still, isn't this a bug?
$ zypper what-provides ghostscript=x11 Reading installed packages... S | Repository | Type | Name | Version | Arch --+------------+---------+---------------------+-----------+------- i | @System | package | ghostscript-library | 8.15.4-17 | x86_64 v | factory | package | ghostscript-library | 8.62-4 | x86_64 v | factory | package | ghostscript-library | 8.62-4 | i586
There should be no providers of ghostscript=x11 or? And similarly for libldtl=3.
If you create a test case with <addRequire name="libltdl = 3"/>, satsolver deptestomatic will say "nothing provides libltdl = 3". But if you call libzypp's deptestomatic it will happily install libltdl-3 And the debug output is as this: [satsolver] PoolImpl.cc(logSat):73 *** Add JOB rules *** [satsolver] PoolImpl.cc(logSat):73 job: install provides libltdl = 3 [satsolver] PoolImpl.cc(logSat):73 Add rule: Rule #70: [satsolver] PoolImpl.cc(logSat):73 libltdl-3-1.5.26-14.i586 [1301] (w1) [satsolver] PoolImpl.cc(logSat):73 next rules: 0 0 So yes, obviously a bug in the sat part of libzypp. Greetings, Stephan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stephan Kulow schrieb:
Am Sonntag, 20. April 2008 schrieb Jano Kupec:
Stephan Kulow wrote:
Am Donnerstag, 17. April 2008 schrieb Jano Kupec:
Stephan Kulow wrote:
Hi,
the live cds are broken since today and I debugged it a bit and the zypper behaviour below kiwi is _very_ weird.
I patched kiwi to call --debug-solver and I get e.g. <addReq name="libltdl = 3"/>
in the zypper command line it was zypper libltdl-3
Who splits the package name? Interestingly enough not all package names. But also "ghostscript = x11" is installed.
Hm, this was supposed to be a nice heuristic, now i see it has some flaws
:O( This was done in order to be able to install like this:
$ zypper install foo-package-1-2.0.3-5
The workflow: for each '-' found in the string { replace '-' with '=' check if there is something wich provides such capability if there is something { use this; break } }
obviously this will not work for libdtl-3 as there obviously are providers of libdtl = 3. Bad idea :O(
Why not check first if something provides libltdl-3 ? BTW: I noticed this only because the live cds were enlarged by as little as 70MB due to kernel-source.rpm providing "linux".
Yes, this works, plus (if nothing provides the original string) i start to replace dashes for '=' from right to left. I can't think of any other way how it could fail now, but still if you want to install by name only, you can force it with --name option (although this way zypper chooses the version to install, not the solver).
But still, isn't this a bug?
$ zypper what-provides ghostscript=x11 Reading installed packages... S | Repository | Type | Name | Version | Arch --+------------+---------+---------------------+-----------+------- i | @System | package | ghostscript-library | 8.15.4-17 | x86_64 v | factory | package | ghostscript-library | 8.62-4 | x86_64 v | factory | package | ghostscript-library | 8.62-4 | i586
There should be no providers of ghostscript=x11 or? And similarly for libldtl=3.
If you create a test case with <addRequire name="libltdl = 3"/>, satsolver deptestomatic will say "nothing provides libltdl = 3". But if you call libzypp's deptestomatic it will happily install libltdl-3
You have called a 10.3 libzypp's deptestomatic ;-) or ? <addRequire name="libltdl = 3"/> This does not work with the helixparser of the SAT Solver cause it is a namedependency only.
And the debug output is as this: [satsolver] PoolImpl.cc(logSat):73 *** Add JOB rules *** [satsolver] PoolImpl.cc(logSat):73 job: install provides libltdl = 3 [satsolver] PoolImpl.cc(logSat):73 Add rule: Rule #70: [satsolver] PoolImpl.cc(logSat):73 libltdl-3-1.5.26-14.i586 [1301] (w1) [satsolver] PoolImpl.cc(logSat):73 next rules: 0 0
So yes, obviously a bug in the sat part of libzypp.
Greetings, Stephan
-- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, 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
Am Montag, 21. April 2008 schrieben Sie:
You have called a 10.3 libzypp's deptestomatic ;-) or ? <addRequire name="libltdl = 3"/>
This does not work with the helixparser of the SAT Solver cause it is a namedependency only.
And the debug output is as this: [satsolver] PoolImpl.cc(logSat):73 *** Add JOB rules *** [satsolver] PoolImpl.cc(logSat):73 job: install provides libltdl = 3 [satsolver] PoolImpl.cc(logSat):73 Add rule: Rule #70: [satsolver] PoolImpl.cc(logSat):73 libltdl-3-1.5.26-14.i586 [1301] (w1) [satsolver] PoolImpl.cc(logSat):73 next rules: 0 0
So yes, obviously a bug in the sat part of libzypp.
How can 10.3's libzypp triggere the above debug output? I doubt it has too much satsolver inside. Greetings, Stephan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stephan Kulow schrieb:
Am Montag, 21. April 2008 schrieben Sie:
You have called a 10.3 libzypp's deptestomatic ;-) or ? <addRequire name="libltdl = 3"/>
This does not work with the helixparser of the SAT Solver cause it is a namedependency only.
And the debug output is as this: [satsolver] PoolImpl.cc(logSat):73 *** Add JOB rules *** [satsolver] PoolImpl.cc(logSat):73 job: install provides libltdl = 3 [satsolver] PoolImpl.cc(logSat):73 Add rule: Rule #70: [satsolver] PoolImpl.cc(logSat):73 libltdl-3-1.5.26-14.i586 [1301] (w1) [satsolver] PoolImpl.cc(logSat):73 next rules: 0 0
So yes, obviously a bug in the sat part of libzypp.
How can 10.3's libzypp triggere the above debug output? I doubt it has too much satsolver inside.
A good argument :-) . Send me the testcase.....
Greetings, Stephan
-- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, 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
participants (5)
-
Jan-Simon Möller -
Jano Kupec -
Klaus Kaempf -
Stefan Schubert -
Stephan Kulow