[zypp-devel] is this a bug in libzypp?
I'm busy debugging the lilypond build in home:plater:lilypond and this involves adding various packages to the sub project to try to get the same build results in 11.3, 11.4 and factory repos. To avoid network noise I use an unattended cron job to do a zypper dup of KDF and the above mentioned repo to my x86_64 11.4 system. A test "zypper -v dup -r plalily" today has alarmed me as it wanted to install all the i586 ghostscript rpms from the ghostscript-library package. I went through /etc/zypp/zypp.conf and couldn't find any option to prevent this from happening. There is something wrong with the repo as even after deleting the i586 binaries from 11.4 the i586 directory still has ghostscript but x86_64 has nothing, this is not a libzypp problem the problem is that if this happens in KDE:Distro:Factory for instance I'll end up with a whole bunch of i586 rpms installed. Why is libzypp allowed to change x86_64 packages to i586 silently? I understand the reasoning behind having i586 packages that have never had x86_64 versions and are supported by 32 bit x86_64 libs but allowing an i586 package to replace an x86_64 one without asking has no logic in it at all and there should be a mechanism in place to allow a user to prevent this. Thanks Dave P -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On 09/22/2011 09:43 PM, Dave Plater wrote:
I'm busy debugging the lilypond build in home:plater:lilypond and this involves adding various packages to the sub project to try to get the same build results in 11.3, 11.4 and factory repos. To avoid network noise I use an unattended cron job to do a zypper dup of KDF and the above mentioned repo to my x86_64 11.4 system. A test "zypper -v dup -r plalily" today has alarmed me as it wanted to install all the i586 ghostscript rpms from the ghostscript-library package. I went through /etc/zypp/zypp.conf and couldn't find any option to prevent this from happening. There is something wrong with the repo as even after deleting the i586 binaries from 11.4 the i586 directory still has ghostscript but x86_64 has nothing, this is not a libzypp problem the problem is that if this happens in KDE:Distro:Factory for instance I'll end up with a whole bunch of i586 rpms installed. Why is libzypp allowed to change x86_64 packages to i586 silently? I understand the reasoning behind having i586 packages that have never had x86_64 versions and are supported by 32 bit x86_64 libs but allowing an i586 package to replace an x86_64 one without asking has no logic in it at all and there should be a mechanism in place to allow a user to prevent this.
Thanks Dave P
Solved ghostscript but now I have this to contend with, bear in mind that my existing texlive is x86_64 and you will understand the chaos in rpmbuild that would be caused by the lib...so being in /usr/lib and not lib64: The following package is going to change architecture: texlive-bin-devel 2010-4.6 -> 2011-52.1 x86_64 -> i586 These are all mega packages and take a while to build in obs and even more time to sync all the packages with each other. Is there a work around at least? Thanks Dave P -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thursday 22 September 2011 21:43:32 Dave Plater wrote:
the above mentioned repo to my x86_64 11.4 system. A test "zypper -v dup -r plalily" today has alarmed me as it
NEVER do "zypper -v dup -r <repo>" unless you really want what it's doing. The resolver roughly classifies installed packages into 'wanted' and 'unwanted' (maybe someone has better words for it): If some package (or an update candidate for it) is provided by some repo, it is 'wanted'. If it is not, it's considered to be 'unwanted', 'orphaned' or 'dropped' - A leftover of ancient times, still installed on the system because it did not make trouble. If it makes trouble it can be removed. Now 'zypper -r <repo>' turns of all repositories except for '<repo>'. Thus the solver will consider all installed packages originating from other repos as being 'unwanted'. If dependency problems occur, the solver is not able to resolve them with packages from other (core) repos, because he does not see those repos. So the solver will consider removing 'unwanted' packages involved in the conflict. This is most probably not what you want. "zypper -r" is usefull when searching, as it reduces the time spent on loading repos. When installing packages it's use is very limited, and it should not be used unattended. You probably want: 'zypper dup --from <repo>' Replace all installed packages, which are provided by this repo, with the best version from this repo. In this mode all your other repos are visible to the solver, so no packages will accidentally be classified as 'unwanted'. The solver will also be able to pick missing dependencies from other repos, rather than considering to remove the unresolvable parts. The solver will not remove 'wanted' packages, if he had to in order to perform the job, a conflict will be generated and you have to approve it. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On 09/23/2011 12:55 PM, Michael Andres wrote:
On Thursday 22 September 2011 21:43:32 Dave Plater wrote:
the above mentioned repo to my x86_64 11.4 system. A test "zypper -v dup -r plalily" today has alarmed me as it
NEVER do "zypper -v dup -r<repo>" unless you really want what it's doing.
The resolver roughly classifies installed packages into 'wanted' and 'unwanted' (maybe someone has better words for it):
If some package (or an update candidate for it) is provided by some repo, it is 'wanted'. If it is not, it's considered to be 'unwanted', 'orphaned' or 'dropped' - A leftover of ancient times, still installed on the system because it did not make trouble. If it makes trouble it can be removed.
Now 'zypper -r<repo>' turns of all repositories except for'<repo>'. Thus the solver will consider all installed packages originating from other repos as being 'unwanted'. If dependency problems occur, the solver is not able to resolve them with packages from other (core) repos, because he does not see those repos. So the solver will consider removing 'unwanted' packages involved in the conflict. This is most probably not what you want.
"zypper -r" is usefull when searching, as it reduces the time spent on loading repos. When installing packages it's use is very limited, and it should not be used unattended.
You probably want: 'zypper dup --from<repo>' Replace all installed packages, which are provided by this repo, with the best version from this repo.
In this mode all your other repos are visible to the solver, so no packages will accidentally be classified as 'unwanted'. The solver will also be able to pick missing dependencies from other repos, rather than considering to remove the unresolvable parts. The solver will not remove 'wanted' packages, if he had to in order to perform the job, a conflict will be generated and you have to approve it.
I just discovered that 11.4 zypper dup has --from which I use exclusively with zypper in. I've been using zypper dup -r kde4 to update my kdf for a long time as I maintain and contribute to a few kde packages and I have separate sub projects for lilypond and blender which I use zypper dup -r to test the packages, blender because I also maintain libOpenCollada and the two are linked plus it needs python3 >= 3.2 Lilypond uses ghostscript, text, fontforge and friends plus guile the latter is causing a factory build failure because of the update to guile 2.0, not to mention a ghostscript segfault so I group all these packages into home:plater:lilypond to try to get the same behaviour in factory and 11.4 also to make sure that the right packages are pulled in by a zypper dup or a zypper in. Another example that I don't quite understand is : I've just updated multimedia:libs libkate from 0.3.8 to 0.4.1 and it's on it's way to factory. I split off liboggkate1 from libkate1 and added "Obsoletes: libkate1 < 0.4.1" and "Provides: %{_libdir}/liboggkate.so.1" to the liboggkate1 package with the result that neither zypper dup -r, zypper dup --from or zypper up -r, pick it up, why is this? I think a packagers most important job is to ensure clean updates be they from update, from the devel project or a dup to the next version. I'll create an artificial situation by deleting the x86_64 binaries and try a zypper dup --from (when the #$@%^& build service is up again) to see if it ignores the i586 binaries. If it doesn't, should I file a bug or a feature request? I can remember this situation occurring in earlier times when factory contained only i586 packages due to an error causing a noise on the factory list and I have also had stray i586 packages appearing inexplicably. I've changed my kdf dup cron job from -r to --from and as with in I shall use --from exclusively from now on. Thinking about it more, I should actually use zypper up -r kde4 to keep my kdf up to date as zypper dup is only necessary to change vendor which I don't need to do in this case "dup" is necessary when I test lilypond and blender because I need factory equivalent packages to be installed on my 11.4 system and in the case of blender any 11.4 user who wants the 2.59 version needs to install from home:plater:blender due to it's python >= 3.2 dependency. Sorry for the long message but there needs to be good communication between packager and installation system maintainer and your comments will be appreciated. Dave -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (3)
-
Dave Plater -
Dave Plater -
Michael Andres