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