Richard Brown composed on 2015-03-07 16:59 (UTC+0100):
You're only half correct - the primary reason for dup is to allow zypper to search all repositories, all vendors, for the latest version of the packages for the system
This is important for upgrading from one Regular Release version to another (eg 13.1 to 13.2) because the repositories are changing, from 13.1 to 13.2
Absolutely.
In the case of Tumbleweed - the repositories do not change, even
Standard repo names don't change, but unlike regular releases, what's in them routinely changes. Dependencies change. Major versions change, usually up, sometimes down. Some packages disappear. Others are introduced.
though you're correct that technically each Tumbleweed snapshot is a new OS version.
+1
For most people upgrading Tumbleweed, zypper up makes perfect sense In lay terms, you're telling zypper "get me the latest updates that match the packages/repositories I installed. Don't change repos, don't change vendors, just gimme updates for what I installed, from where I installed it'
At some point this means no longer running TW, because TW changes, and you wind up using orphans, if you only ever use up.
zypper dup on the otherhand is a lot more risky "Give me the latest version of everything from anywhere I have configured". Depending on your combination of repositories, that can lead to unexpected integration problems. Even with a single additional repository, it's worth keeping in mind we only openQA test the main Tumbleweed repos, we -know- that works every snapshot, we -hope- it works with everything else.
If you have other repos configured, you're not using TW, just something based on TW. By taking on other repos you're taking on additional responsibility for your choice, and associated additional risk.
Spelling it out that way, do you see why I don't think recommending zypper dup to everyone using Tumbleweed, all the time, is a good idea?
IOW, you recommend everybody not actually use TW, just claim to be. Without using dup, you're not using TW, just something based on it originally, when you installed it or upgraded to it from a regular release.
So, I'm going to provide my advice - this is what I do - if it's not good advice, may wiser people like Coolo slap me down
Too bad this is a weekend thread. I'm anxious to see what if any response the thread gets from Coolo.
--- MY RECOMMENDED PROCEDURE --- For Daily/Regular 'I want to update my system' patching of openSUSE Tumbleweed, use zypper up --- /END MY RECOMMEND PROCEDURE
This advice is doubled in strength, loudness, and intensity, if you're using additional repositories, such as Packman, in order to avoid potential unexpected extra packages from those repositories.
This is fine for those whose use case is uniqueness. Once other repos are added, it isn't TW any more, but a hybrid. Hybrids require more interaction from the user, and unavoidably, add risk. To more easily deal with risk, what Neil does makes sense. First up, then dup -D to segregate out the more significant changes, and optionally disable any that might be a problem you want to avoid via locks, before actually dup'ing.
Occasionally, it might be a good idea to do a zypper dup, just in case, as an extra maintenance step, on the off chance something in the openSUSE Tumbleweed repos got downgraded or otherwise shifted about in a way that zypper up misses.
"Off chance"? Downgrades happen. Orphans happen. Deps change. It's not a question of whether, only when.
This is a relatively safe procedure we no additional repositories, however, you need to take care with any additional repositories, either taking note what is shifting over to them, or disabling them and adding back what is missing afterwards.
If risk is a problem, you're using the wrong release. TW is not for you.
I wouldn't want to do that every day.
Every day implies low risk aversion. High risk aversion implies TW is a poor choice. If you need something from a non-standard repo, you need to be involved, less risk averse, as you're not using TW any more once you've made such an addition. I handle optional repo packages via repo management, and locks. If I need one package, I may just fetch it with web browser, mc(ftp) or wget. That way I have the package on disk to remind me after installing it if I have chosen to not set a lock on it. For a related group of packages within a repo, I enable the repo, install the packages, then disable the repo, so that a subsequent dup won't pull other packages from it; and optionally lock as many of the installed packages as required to prevent "downgrade" or "vendor change" on a subsequent dup. Dup functions as a synchronizer, tumbling the installation along as TW itself tumbles, removing what the repos no longer contain, matching installed versions to what the repos do contain. Technically, using up to the exclusion of dup amounts to not using TW, just something that used to be. -- "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