On 9 February 2017 at 09:28, Johannes Kastl wrote:

On 09.02.17 08:57 Roger Oberholtzer wrote:

...

On an existing Tumbleweed, if I do a zypper dup, isn't it the case that I would get the packages described in the latest e-mail about a snapshot

Exactly.

...

- as well as any packages that have been updated and are perhaps destined for the next snapshot. That is, a zypper dup is not limited to the packages in the last Tumbleweed snapshot that have passed QA.

No. Let me try to explain, although I will probably mix some things up myself.

Packages dont go into tumbleweed directly. They go into 'factory', are being tested via openQA and are then released as a tumbleweed snapshot.

What you get with zypper dup is what passed openQA and was released as a snapshot.

In OBS you see the difference when looking at a repository definition, either it is standard or snapshot.

<repository name="openSUSE_Tumbleweed"> <path project="openSUSE:Factory" repository="snapshot"/> <arch>i586</arch> <arch>x86_64</arch> </repository>

Johannes

Yup, correct. you can also use the path project="openSUSE:Tumbleweed" which is effectively just an alias to <path project="openSUSE:Factory" repository="snapshot"/> But to answer the original question of 'how best to update Tumbleweed' In my opinion, the short answer is: zypper dup --no-allow-vendor-change the long answer: zypper dup is fine and perfectly safe when using Tumbleweed with only the official Tumbleweed repositories But as soon as you start adding OBS repos you end up with a number of potential problems, the two main ones are 1) the OBS repos you've picked may or may not have actually built against the snapshot in question, leading to potentially packages you actually need being removed in order to solve zypper dups dependency logic. These build issues could just be a timing issue (ie. the repo will catch up later) or a legitimate issue (as Tumbleweed moves, sooner or later packages in OBS repos will need to be adjusted to build against it). If you're dealing with a package that originally came from TW, then you replaced it with an OBS repo, this can lead to your package reverting back to the TW one. Otherwise this can lead to your package being removed. 2) OBS repos can include whatever packages the maintainers want them to. This means they can freely include packages that normally originate from Tumbleweed or other OBS repos. As zypper dup just tries to grab the latest version of any package from any repo, this effectively means other repos can 'hijack' the package and give you their version rather than the one you expected. both of these problems hurt users when behaviour that worked yesterday suddenly breaks. zypper up is a partial solution, as it doesn't allow packages to change their repos (aka vendor change), but has its own flaws, as it is often too conservative and doesn't tidy up after itself. This can lead to old packages lying around after they've been dropped from TW or your OBS repos, leading to weird dependency chains of old packages lurking around when you should have actually upgraded them all. this also leads to weird breakages and odd behaviour. "zypper dup --now-allow-vendor-change" forces zypper dup to use the most important feature of zypper up "keep using the packages from the same repositories from which I installed them from". But otherwise preserves all the usual zypper dup behaviour of ensuring you have a complete, consistent, tumbleweed installation based on what packages are, or are no longer, in our repositories. This avoids the issues with 'zypper up' leaving 'cruft', prevents the problem described in 2), and does the best job possible to mitigate the problems described in 1) - but of course you're still at the mercy of whatever maintainers do in their OBS repos, and they do not benefit from the review, integration work, and testing which the main repositories benefit from. Hope this helps, R -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il 09/02/2017 08:35, Andrea Controzzi - LedMania.it ha scritto:

On 09/02/2017 09:59, Richard Brown wrote:

...

On 9 February 2017 at 09:28, Johannes Kastl wrote:

...

On 09.02.17 08:57 Roger Oberholtzer wrote:

...

On an existing Tumbleweed, if I do a zypper dup, isn't it the case that I would get the packages described in the latest e-mail about a snapshot Exactly.

...

- as well as any packages that have been updated and are perhaps destined for the next snapshot. That is, a zypper dup is not limited to the packages in the last Tumbleweed snapshot that have passed QA. No. Let me try to explain, although I will probably mix some things up myself.

Packages dont go into tumbleweed directly. They go into 'factory', are being tested via openQA and are then released as a tumbleweed snapshot.

What you get with zypper dup is what passed openQA and was released as a snapshot.

In OBS you see the difference when looking at a repository definition, either it is standard or snapshot.

<repository name="openSUSE_Tumbleweed"> <path project="openSUSE:Factory" repository="snapshot"/> <arch>i586</arch> <arch>x86_64</arch> </repository>

Johannes Yup, correct. you can also use the path project="openSUSE:Tumbleweed" which is effectively just an alias to <path project="openSUSE:Factory" repository="snapshot"/>

But to answer the original question of 'how best to update Tumbleweed'

In my opinion, the short answer is: zypper dup --no-allow-vendor-change

the long answer:

zypper dup is fine and perfectly safe when using Tumbleweed with only the official Tumbleweed repositories

But as soon as you start adding OBS repos you end up with a number of potential problems, the two main ones are

1) the OBS repos you've picked may or may not have actually built against the snapshot in question, leading to potentially packages you actually need being removed in order to solve zypper dups dependency logic. These build issues could just be a timing issue (ie. the repo will catch up later) or a legitimate issue (as Tumbleweed moves, sooner or later packages in OBS repos will need to be adjusted to build against it). If you're dealing with a package that originally came from TW, then you replaced it with an OBS repo, this can lead to your package reverting back to the TW one. Otherwise this can lead to your package being removed.

2) OBS repos can include whatever packages the maintainers want them to. This means they can freely include packages that normally originate from Tumbleweed or other OBS repos. As zypper dup just tries to grab the latest version of any package from any repo, this effectively means other repos can 'hijack' the package and give you their version rather than the one you expected.

both of these problems hurt users when behaviour that worked yesterday suddenly breaks.

zypper up is a partial solution, as it doesn't allow packages to change their repos (aka vendor change), but has its own flaws, as it is often too conservative and doesn't tidy up after itself. This can lead to old packages lying around after they've been dropped from TW or your OBS repos, leading to weird dependency chains of old packages lurking around when you should have actually upgraded them all.

this also leads to weird breakages and odd behaviour.

"zypper dup --now-allow-vendor-change" forces zypper dup to use the most important feature of zypper up "keep using the packages from the same repositories from which I installed them from". But otherwise preserves all the usual zypper dup behaviour of ensuring you have a complete, consistent, tumbleweed installation based on what packages are, or are no longer, in our repositories.

This avoids the issues with 'zypper up' leaving 'cruft', prevents the problem described in 2), and does the best job possible to mitigate the problems described in 1) - but of course you're still at the mercy of whatever maintainers do in their OBS repos, and they do not benefit from the review, integration work, and testing which the main repositories benefit from.

Hope this helps, R Great explanation, Richard. I might also add that --no-allow-vendor-change means that when a vendor change is somehow required (i.e. to satisfy a dependence) , zypper tells you and gives you the option to do or do not that change. So you basically know more what is going on, instead of hoping for the best, which with other OBS is always not granted.

Andrea.

Dears, I use to execute */zypper ref && zypper up/* because I configured also other repositories and so far so good. Does my method is safe and grants me the latest updates? Tks. Cheers, -- Marco Calistri Opensuse Tumbleweed 64 bit Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 Intel® Sandybridge Mobile N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�

On Thu, Feb 9, 2017 at 3:21 PM, Patrick Shanahan wrote:

if "other repositories" means not the base openSUSE Tumbleweed repos, you need "dup" and "--no-allow-verndor-change" as "up" causes problems, no matter who does the configuring.

I don't know if I haven't understood something obvious but zypper dup --no-allow-vendor-change doesn't work for me. It asks to change the repo for some packman packages sudo zypper dup --no-allow-vendor-change Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data... Reading installed packages... Computing distribution upgrade... 8 Problems: Problem: problem with installed package amarok-2.8.0-36.9.x86_64 Problem: problem with installed package libchromaprint1-1.3.1-30.7.x86_64 Problem: problem with installed package libguess1-1.2-11.10.x86_64 Problem: problem with installed package libkcddb16-16.07.0-5.7.x86_64 Problem: problem with installed package libluajit-5_1-2-2.1.0~beta2-16.2.x86_64 Problem: problem with installed package libnfs-1.10.0-1.7.x86_64 Problem: problem with installed package libopencv3_1-3.1.0-88.30.x86_64 Problem: problem with installed package libsoxr0-0.1.2-12.7.x86_64 Problem: problem with installed package amarok-2.8.0-36.9.x86_64 Solution 1: install amarok-2.8.0-26.1.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): Choosing "skip" on all packages just recycles the procedure. Am I missing something?

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Didn't know that. Thanks! On Thu, Feb 9, 2017 at 4:18 PM, Richard Brown wrote:

On 9 February 2017 at 15:12, Stratos Zolotas wrote:

...

On Thu, Feb 9, 2017 at 3:21 PM, Patrick Shanahan wrote:

...

if "other repositories" means not the base openSUSE Tumbleweed repos, you need "dup" and "--no-allow-verndor-change" as "up" causes problems, no matter who does the configuring.

I don't know if I haven't understood something obvious but zypper dup --no-allow-vendor-change doesn't work for me. It asks to change the repo for some packman packages

sudo zypper dup --no-allow-vendor-change Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data... Reading installed packages... Computing distribution upgrade... 8 Problems: Problem: problem with installed package amarok-2.8.0-36.9.x86_64 Problem: problem with installed package libchromaprint1-1.3.1-30.7.x86_64 Problem: problem with installed package libguess1-1.2-11.10.x86_64 Problem: problem with installed package libkcddb16-16.07.0-5.7.x86_64 Problem: problem with installed package libluajit-5_1-2-2.1.0~beta2-16.2.x86_64 Problem: problem with installed package libnfs-1.10.0-1.7.x86_64 Problem: problem with installed package libopencv3_1-3.1.0-88.30.x86_64 Problem: problem with installed package libsoxr0-0.1.2-12.7.x86_64

Problem: problem with installed package amarok-2.8.0-36.9.x86_64 Solution 1: install amarok-2.8.0-26.1.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE

Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c):

Choosing "skip" on all packages just recycles the procedure. Am I missing something?

No, the correct option is 1

Amarok is no longer built for Tumbleweed by Packman

You should be getting it from openSUSE, just like zypper dup --no-allow-vendor-change is telling you. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Patrick Shanahan wrote:

if "other repositories" means not the base openSUSE Tumbleweed repos, you need "dup" and "--no-allow-verndor-change" as "up" causes problems, no matter who does the configuring. Unfortunately I am unsuccessful with the "zypper dup --no-allow-vendor-change" command.

Zypper calculates 95 problems on my main PC. Zypper offers exactly 1 solution for each of the 95 problems. It suggest to change packages from Packman to openSUSE, from KDE to KDE:Extra etc. Also Zypper suggest to choose some self-compiled RPMs with "official" RPMs from repositories. # zypper dup --no-allow-vendor-change Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data... Reading installed packages... Computing distribution upgrade... 95 Problems: Problem: problem with installed package MozillaFirefox-50.1.0-573.1.x86_64 Problem: problem with installed package cantata-2.0.1-0.x86_64 [...] Problem: problem with installed package MozillaFirefox-50.1.0-573.1.x86_64 Solution 1: install MozillaFirefox-51.0.1-577.10.x86_64 (with vendor change) obs://build.opensuse.org/home:bjoernv --> obs://build.opensuse.org/mozilla Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): 1 Problem: problem with installed package cantata-2.0.1-0.x86_64 Solution 1: install cantata-2.0.1-1.19.x86_64 (with vendor change) obs://build.opensuse.org/home:bjoernv --> obs://build.opensuse.org/KDE:Extra Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): s Problem: problem with installed package fdupes-1.51-3.20.x86_64 Solution 1: install fdupes-1.61-1.1.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): It offers 4 options: 1 (solution 1), s)kip, r)etry and c)ancel. If I refuse only one suggestion with "skip" Zypper comes to an endless loop. If I answered the 95 questions with at least only answer "skip", Zypper starts again. So if I have to say "Yes" to everything, I don't see the difference between "zypper dup --no-allow-vendor-change" and "zypper dup". Especially "zypper dup --no-allow-vendor-change" does not preserve my repository preferences for me. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 西元2017年02月12日 08:48, Carlos E. R. wrote:

Usually there is a good reason for that. On packman, it is possible those packages did disappear from packman.

fdupes, as mentioned, is a well-known example of that. Additionally, it might be better to switch all packages to Tumbleweed with a sudo zypper dup --from 1, then reinstall specific packages from the vendor of your choice. Use zypper dup --no-allow-vendor-change from then on to keep things clean.

* Aleksa Sarai [02-12-17 09:01]:

...

So if I have to say "Yes" to everything, I don't see the difference between "zypper dup --no-allow-vendor-change" and "zypper dup". Especially "zypper dup --no-allow-vendor-change" does not preserve my repository preferences for me.

--no-allow-vendor-change means that Zypper will not automatically switch vendors for *every package which has a newer version in another repo*. But sometimes the depsolver figures out that the only solution is to switch vendors (in order to upgrade some package) -- which is why it's asking you to confirm vendor changes.

If you don't set --no-allow-vendor-change, you'll see *a lot more* than 95 vendor changes. Zypper is only asking you about the unavoidable ones.

And *only* now because you have not previously followed the advised path. When you add repos besides those advised, you create the conditions you now see. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12 February 2017 at 11:59, Olaf Hering wrote:

Am 11. Februar 2017 23:04:33 MEZ schrieb Bjoern Voigt :

...

Zypper calculates 95 problems on my main PC.

This sort of setup should be handled with repo priorities. First home, then Mozilla, then Packman, then Tumbleweed (or whatever you want the stacking to be). Then a simple 'zypper dup' would give a consistent state. This will cover eventual ABI changes within a repo. This requires that each repo is clean and carries no duplicated package, which might be the case in badly maintained repos.

Olaf, your advice only holds true if you trust the admin of the home repo more than the admin of Mozilla and the admin for Packman more than the admins of Tumbleweed. As repo prios automatically switch any and all packages to the repo of highest priority, unless you can assert that trust with significant confidence, the advice to use repos is stupid. I would only recommend priorities with that huge "caveat emptor" attached - Users of priorities choose to trust these repositories more than the official openSUSE Project and should understand that they are fully responsible for anything bad that happens to their machine as a result. I can count the people who's home repo I would trust to that degree on one hand, and even then I'd discuss with them a better solution than using their home repo. Mozilla, sure, MAYBE, would be the one repo in your list that I would consider given a higher priority for, because Wolfgang knows what he's doing and he's earned that trust and shown his capability to maintainer repositories properly with Evergreen. But packman, seriously? I hate to be so overly critical but the administration of Packman has been a joke for years, with terrible ill informed decisions made by the maintainers. While packman is slowly improving (and I know I have you to partially thank for that), this gentlemens 95 errors are symptomatic of the problems Packman has created and has only recently started to address. I think it's a long while before I'll trust Packman to the level you're suggesting here. Proper quality controls, review processes, and clear policies about what Packman will include and not, are all needed to improve Packmans credibility in this area. Until then, please do not recommend priorities, or if you do, please make sure you fully explain how the priorities allow repository maintainers control over what packages are on your system and the risks that come with it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday, February 12, 2017 11:59:57 AM PST Olaf Hering wrote:

Am 11. Februar 2017 23:04:33 MEZ schrieb Bjoern Voigt :

...

Zypper calculates 95 problems on my main PC.

This sort of setup should be handled with repo priorities. First home, then Mozilla, then Packman, then Tumbleweed (or whatever you want the stacking to be). Then a simple 'zypper dup' would give a consistent state. This will cover eventual ABI changes within a repo. This requires that each repo is clean and carries no duplicated package, which might be the case in badly maintained repos.

There are likely valid usecases for the --no-allow-vendor-change. But following a repo should be allowed. Take the recent ABI change in libbluray for example. Some struct was changed, all packages in Packman use the new layout. Disallowing vendor change may result in bad runtime behavior because the TW variant of libbluray is installed.

And of course this specific example taints my statement that zypper dup --from Packman is 100% safe. Sorry for that..

Olaf

"This sort of setup should be handled with repo priorities........" +1 , works for me too, https://gist.github.com/anonymous/30dd705885209facfac0996fd96b069f -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Sonntag, 12. Februar 2017, 20:46:45 CET schrieb Mathias Homann:

Am Sonntag, 12. Februar 2017, 08:40:48 CET schrieb emanuel:

...

"This sort of setup should be handled with repo priorities........" +1 , works for me too, https://gist.github.com/anonymous/30dd705885209facfac0996fd96b069f

+100. if not more.

I have TWENTY SIX repos configured in my desktop pc. All sorted into wellbehaving by giving them proper priorities. I just ran a live upgrade directly from 13.2 to Leap 42.2, skipping 42.1, no problems.

ok, TBH, i have one home: repository, which is my own. everything else are "released" repos. like KDE: stuff and such.

okay, but what does that mean precisely: "giving them proper priorities"? Greetings Willi -- openSUSE Tumbleweed 20170211 GNU/Linux 4.9.8-1-default x86_64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday, 12 February 2017 20:46:45 CET Mathias Homann wrote:

Am Sonntag, 12. Februar 2017, 08:40:48 CET schrieb emanuel:

...

"This sort of setup should be handled with repo priorities........" +1 , works for me too, https://gist.github.com/anonymous/30dd705885209facfac0996fd96b069f

+100. if not more.

I have TWENTY SIX repos configured in my desktop pc. All sorted into wellbehaving by giving them proper priorities. I just ran a live upgrade directly from 13.2 to Leap 42.2, skipping 42.1, no problems.

since im quite new perhaps you could confirm my understanding: the libblueray example appears to conflate installation with updating, as does the use of priorities. from UXI perspective for new and non-expert users, (understanding that repo "hygiene" often isnt that good). the 2 methods for UPDATING appear to be: 1 - use zypper dup --no-allow-vendor-change [the end] 2 - priorites: a) learn about the use of priorities and how packages are resolved. b) understand the contents of each repo. c) perform security checks at each update to ensure any OBS packages etc havnt added tainted security critical software. d) if one-click-install is used, understand everything in the new repo and go into system and change the priority for the new repo to the "correct one". e) "know" what is the correct presidence for many different repos. the number of different combinations is exponentially large and as such can never be prescribed. f) know what to do if 2 repos are non-orthogonal i.e. if you want one package from 1 repo but another package from a second repo and we should advocate number 2? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Feb 13, 2017 at 10:20 AM, nicholas wrote:

On Sunday, 12 February 2017 20:46:45 CET Mathias Homann wrote:

...

Am Sonntag, 12. Februar 2017, 08:40:48 CET schrieb emanuel:

...

"This sort of setup should be handled with repo priorities........" +1 , works for me too, https://gist.github.com/anonymous/30dd705885209facfac0996fd96b069f

+100. if not more.

I have TWENTY SIX repos configured in my desktop pc. All sorted into wellbehaving by giving them proper priorities. I just ran a live upgrade directly from 13.2 to Leap 42.2, skipping 42.1, no problems.

since im quite new perhaps you could confirm my understanding:

the libblueray example appears to conflate installation with updating, as does the use of priorities.

from UXI perspective for new and non-expert users, (understanding that repo "hygiene" often isnt that good). the 2 methods for UPDATING appear to be: 1 - use zypper dup --no-allow-vendor-change [the end] 2 - priorites: a) learn about the use of priorities and how packages are resolved. b) understand the contents of each repo. c) perform security checks at each update to ensure any OBS packages etc havnt added tainted security critical software. d) if one-click-install is used, understand everything in the new repo and go into system and change the priority for the new repo to the "correct one". e) "know" what is the correct presidence for many different repos. the number of different combinations is exponentially large and as such can never be prescribed. f) know what to do if 2 repos are non-orthogonal i.e. if you want one package from 1 repo but another package from a second repo

and we should advocate number 2?

I thought most have been advocating option 1. But there is always option 2 if you want to have more involvement in the update process. If a package has a DRM issue, the openSUSE repos may not contain the version that accesses the DRM protected content. Packman libraries, however, will probably allow access. So, it is quite common that one gets media apps from Packman. If the openSUSE repo gets a new version before Packman, zypper may want to install that newer version. If you allow that, you may no longer be able to access DRM content. So, once you have decided to use the package from Packman, you probably want to stay with it. Even if the openSUSE repo may get a new version before Packman. This is true of many packages for various reasons. The --no-allow-vendor-change just means that zypper should not update a package from a different repo without asking if that is what you really want.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Patrick Shanahan wrote:

if "other repositories" means not the base openSUSE Tumbleweed repos, you need "dup" and "--no-allow-verndor-change" as "up" causes problems, no matter who does the configuring.

Unfortunately I am unsuccessful with the "zypper dup --no-allow-vendor-change" command. Zypper calculates 95 problems on my main PC. Zypper offers exactly 1 solution for each of the 95 problems. It suggest to change packages from Packman to openSUSE, from KDE to KDE:Extra etc. Also Zypper suggest to choose some self-compiled RPMs with "official" RPMs from repositories. # zypper dup --no-allow-vendor-change Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Loading repository data... Reading installed packages... Computing distribution upgrade... 95 Problems: Problem: problem with installed package MozillaFirefox-50.1.0-573.1.x86_64 Problem: problem with installed package cantata-2.0.1-0.x86_64 [...] Problem: problem with installed package MozillaFirefox-50.1.0-573.1.x86_64 Solution 1: install MozillaFirefox-51.0.1-577.10.x86_64 (with vendor change) obs://build.opensuse.org/home:bjoernv --> obs://build.opensuse.org/mozilla Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): 1 Problem: problem with installed package cantata-2.0.1-0.x86_64 Solution 1: install cantata-2.0.1-1.19.x86_64 (with vendor change) obs://build.opensuse.org/home:bjoernv --> obs://build.opensuse.org/KDE:Extra Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): s Problem: problem with installed package fdupes-1.51-3.20.x86_64 Solution 1: install fdupes-1.61-1.1.x86_64 (with vendor change) http://packman.links2linux.de --> openSUSE Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): It offers 4 options: 1 (solution 1), s)kip, r)etry and c)ancel. If I refuse only one suggestion with "skip" Zypper comes to an endless loop. If I answered the 95 questions with at least only answer "skip", Zypper starts again. So if I have to say "Yes" to everything, I don't see the difference between "zypper dup --no-allow-vendor-change" and "zypper dup". Especially "zypper dup --no-allow-vendor-change" does not preserve my repository preferences for me. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

...

Also Zypper suggest to choose some self-compiled RPMs with "official" RPMs from repositories.

You have to give your home repo a higher priority (lower pri number). Yes, I thought about this. But I have a practical problem with giving repositories higher priority numbers.

If I for instance find an interesting updated package in a home repository, I do not wish that the package will be downgraded on next "zypper dup --no-allow-vendor-change" run. But if I give the home repository a higher priority, then "zypper dup ..." will update all matching packages with the versions from the home repository. This brings me to the question, why will package vendors change also with the "--no-allow-vendor-change" option? (If this is caused by hard dependencies, Zypper does not explain the dependencies.)

...

So if I have to say "Yes" to everything, I don't see the difference between "zypper dup --no-allow-vendor-change" and "zypper dup". Especially "zypper dup --no-allow-vendor-change" does not preserve my repository preferences for me.

It gets much better if you use it everytime. So you can recommend "zypper dup --no-allow-vendor-change" for daily usage?

Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: El 2017-02-14 a las 09:39 -0500, Patrick Shanahan escribió:

...

This brings me to the question, why will package vendors change also with the "--no-allow-vendor-change" option? (If this is caused by hard dependencies, Zypper does not explain the dependencies.)

--no-allow-v... doesn't allow vendor changes!

No, not always true. See some posts up this thread for examples: Problem: problem with installed package MozillaFirefox-50.1.0-573.1.x86_64 Solution 1: install MozillaFirefox-51.0.1-577.10.x86_64 (with vendor change) obs://build.opensuse.org/home:bjoernv --> obs://build.opensuse.org/mozilla - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlijGOkACgkQja8UbcUWM1yrGAD/dsaVoC/tbGO/zYZEDmr5m4bn QKbdbeBy5EQcy1UCI8ABAIQnMxVM9WpGzJftCjUXPeCgHfPgtXEZ/hC60TgewRNM =yFVv -----END PGP SIGNATURE-----

Carlos E. R. wrote:

...

--no-allow-v... doesn't allow vendor changes!

No, not always true. See some posts up this thread for examples:

Problem: problem with installed package MozillaFirefox-50.1.0-573.1.x86_64 Solution 1: install MozillaFirefox-51.0.1-577.10.x86_64 (with vendor change) obs://build.opensuse.org/home:bjoernv --> obs://build.opensuse.org/mozilla Is there an Zypper-option to show the "problems" more detailed?

I mean, I manually solved the MozillaFirefox problem, but now I have 94 instead of 95 problems. :-( (/var/log/zypper.log only shows the same details like Zypper in console.) Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-02-14 a las 16:36 +0100, Bjoern Voigt escribió:

Carlos E. R. wrote:

...

...

--no-allow-v... doesn't allow vendor changes!

No, not always true. See some posts up this thread for examples:

Problem: problem with installed package MozillaFirefox-50.1.0-573.1.x86_64 Solution 1: install MozillaFirefox-51.0.1-577.10.x86_64 (with vendor change) obs://build.opensuse.org/home:bjoernv --> obs://build.opensuse.org/mozilla Is there an Zypper-option to show the "problems" more detailed?

I think it is "--details" Yes, 90 entries is a real pain. - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlijPNMACgkQja8UbcUWM1zlfQEAjIYPIhStoMCiW736OGBdUbzx ORCQyMwmMkBlGCxeWSoA/iY/AIPZynelzHfOa3jtL96ZE8YTr4LYaFQMoNMP4AiR =qiO4 -----END PGP SIGNATURE-----

Marco Calistri composed on 2017-02-14 17:59 (UTC):

Personally with my TW I always use */"zypper ref && zypper up"

/*And So Far So Good!*/

What does Xorg.0.log say your server version is? Current is 1.19.1 packaged 31 Jan. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: El 2017-02-14 a las 15:29 +0100, Bjoern Voigt escribió:

Carlos E. R. wrote:

...

...

Also Zypper suggest to choose some self-compiled RPMs with "official" RPMs from repositories.

You have to give your home repo a higher priority (lower pri number). Yes, I thought about this. But I have a practical problem with giving repositories higher priority numbers.

If I for instance find an interesting updated package in a home repository, I do not wish that the package will be downgraded on next "zypper dup --no-allow-vendor-change" run. But if I give the home repository a higher priority, then "zypper dup ..." will update all matching packages with the versions from the home repository.

Well, never use zypper dup without --no-allow-vendor-change

This brings me to the question, why will package vendors change also with the "--no-allow-vendor-change" option?

Typically when the package disapears from the current repo, or there is no ohter way to solve the deps.

(If this is caused by hard dependencies, Zypper does not explain the dependencies.)

...

...

So if I have to say "Yes" to everything, I don't see the difference between "zypper dup --no-allow-vendor-change" and "zypper dup". Especially "zypper dup --no-allow-vendor-change" does not preserve my repository preferences for me.

It gets much better if you use it everytime. So you can recommend "zypper dup --no-allow-vendor-change" for daily usage?

That seems to be the consensus, yes. The previous reccomendation was to use "zypper dup" and no extra repos, which of course, could not be done... May work adjusting the dependencies. "zypper up" is also problematic on factory/tumbleweed, doesn't solve correctly all the situations. - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlijFtgACgkQja8UbcUWM1y4dQD7Be3GWE3bu0+cOL5lBWo3JIta TNR1RtfhJU61bh9xV7EA/jB13/RY5mMG6VygVrHB58mw1Q1e1gTCxOF5zMseONSD =MhK6 -----END PGP SIGNATURE-----

Op donderdag 9 februari 2017 09:59:58 CET schreef Richard Brown:
> On 9 February 2017 at 09:28, Johannes Kastl  wrote:
> > On 09.02.17 08:57 Roger Oberholtzer wrote:
> >> On an existing Tumbleweed, if I do a zypper dup, isn't it the case
> >> that I would get the packages described in the latest e-mail about a
> >> snapshot
> > 
> > Exactly.
> > 
> >>  - as well as any packages that have been updated and are
> >> 
> >> perhaps destined for the next snapshot. That is, a zypper dup is not
> >> limited to the packages in the last Tumbleweed snapshot that have
> >> passed QA.
> > 
> > No. Let me try to explain, although I will probably mix some things up
> > myself.
> > 
> > Packages dont go into tumbleweed directly. They go into 'factory', are
> > being tested via openQA and are then released as a tumbleweed snapshot.
> > 
> > What you get with zypper dup is what passed openQA and was released as
> > a snapshot.
> > 
> > In OBS you see the difference when looking at a repository definition,
> > either it is standard or snapshot.
> > 
> >   
> >   
> >     
> >     i586
> >     x86_64
> >   
> >   
> > 
> > Johannes
> 
> Yup, correct. you can also use the path project="openSUSE:Tumbleweed"
> which is effectively just an alias to  repository="snapshot"/>
> 
> But to answer the original question of 'how best to update Tumbleweed'
> 
> In my opinion, the short answer is: zypper dup --no-allow-vendor-change
> 
> the long answer:
> 
> zypper dup is fine and perfectly safe when using Tumbleweed with only
> the official Tumbleweed repositories
> 
> But as soon as you start adding OBS repos you end up with a number of
> potential problems, the two main ones are
> 
> 1) the OBS repos you've picked may or may not have actually built
> against the snapshot in question, leading to potentially packages you
> actually need being removed in order to solve zypper dups dependency
> logic. These build issues could just be a timing issue (ie. the repo
> will catch up later) or a legitimate issue (as Tumbleweed moves,
> sooner or later packages in OBS repos will need to be adjusted to
> build against it). If you're dealing with a package that originally
> came from TW, then you replaced it with an OBS repo, this can lead to
> your package reverting back to the TW one. Otherwise this can lead to
> your package being removed.
> 
> 2) OBS repos can include whatever packages the maintainers want them
> to. This means they can freely include packages that normally
> originate from Tumbleweed or other OBS repos. As zypper dup just tries
> to grab the latest version of any package from any repo, this
> effectively means other repos can 'hijack' the package and give you
> their version rather than the one you expected.
> 
> both of these problems hurt users when behaviour that worked yesterday
> suddenly breaks.
> 
> zypper up is a partial solution, as it doesn't allow packages to
> change their repos (aka vendor change), but has its own flaws, as it
> is often too conservative and doesn't tidy up after itself. This can
> lead to old packages lying around after they've been dropped from TW
> or your OBS repos, leading to weird dependency chains of old packages
> lurking around when you should have actually upgraded them all.
> 
> this also leads to weird breakages and odd behaviour.
> 
> "zypper dup --now-allow-vendor-change" forces zypper dup to use the
> most important feature of zypper up "keep using the packages from the
> same repositories from which I installed them from". But otherwise
> preserves all the usual zypper dup behaviour of ensuring you have a
> complete, consistent, tumbleweed installation based on what packages
> are, or are no longer, in our repositories.
> 
> This avoids the issues with 'zypper up' leaving 'cruft', prevents the
> problem described in 2), and does the best job possible to mitigate
> the problems described in 1) - but of course you're still at the mercy
> of whatever maintainers do in their OBS repos, and they do not benefit
> from the review, integration work, and testing which the main
> repositories benefit from.
> 
> Hope this helps,
> R

Great reply, Richard.

>From personal experience:
- zypper up: will result in a mess, maybe not now(), but it will
- zypper dup: will result in f.e. moving back to openSUSE packages where you 
want the Packman ones.
- zypper dup --no-allow-vendor-change: will result in a system update/upgrade 
with preservation of your "repo preferences". 

-- 
Gertjan Lettink, a.k.a. Knurpht

openSUSE Board Member
openSUSE Forums Team
-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 9. Februar 2017 12:46:15 MEZ schrieb Knurpht - Gertjan Lettink :

- zypper dup: will result in f.e. moving back to openSUSE packages where you want the Packman ones.

If you come across an overlapping pkg with equal or lower release number then please let us know. Right now each _link has cicount=add. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Donnerstag, den 09.02.2017, 15:07 +0100 schrieb Jan Engelhardt:

Essentials/eigen3 for example appears to have no link, so would have  that problem.

It builds only for SLE_12, and publish is disabled.

(I used `osc ls` through an interconnect, but I would hope that it does not hide _links.)

osc ls -u prj/pkg Olaf

Am Donnerstag, den 09.02.2017, 15:41 +0100 schrieb Jan Engelhardt:

qosc ls -u packman:Essentials/eigen3 Yes it's missing a _link and so won't get the automatic number updates.

Not sure what "packman:" is: ls(1) shows a link and osc meta pkg shows its SLE_12 only and publish is disabled. I suggest to fix the interconnect. Olaf

On Thu, Feb 09, Jan Engelhardt wrote:

("Show unmerged sources" pops up the _link).

PMBS does not have that capability for whatever reason. Olaf