9 Feb
2017
9 Feb
'17
11:46
Op donderdag 9 februari 2017 09:59:58 CET schreef Richard Brown: > On 9 February 2017 at 09:28, Johannes Kastlwrote: > > 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. > > > > > > > > > > > > Johannes > > Yup, correct. you can also use the path project="openSUSE:Tumbleweed" > which is effectively just an alias to> > i586 > >x86_64 > > > >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