Mailinglist Archive: opensuse-factory (807 mails)

< Previous Next >
Re: [opensuse-factory] Tumbleweed snapshot question
On 09/02/2017 09:59, Richard Brown wrote:
On 9 February 2017 at 09:28, Johannes Kastl <mail@xxxxxxxxxx> 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.


--
Andrea "Kontorotsui" Controzzi
Contact: +39 392 9989834 - +39 050 644097
Skype: Kontorotsui
Settore tecnico / Technical Department - www.LedMania.it
-----
LedMania SRL unipersonale
Via Galilei 27
56042 Lavoria (PI)
P.IVA: 01941970509

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

< Previous Next >
Follow Ups