Best practice for updating system?

English Applications
#1

First, the repositories I currently have:

user1@linux-cdm8:~> zypper lr -d
Las prioridades del repositorio no tienen efecto. Todos los repositorios habilitados comparten la misma prioridad.

#  | Alias                     | Nombre                                  | Habilitado | Comprobación GPG | Actualizar | Prioridad | Tipo   | URI                                                                           | Servicio
---+---------------------------+-----------------------------------------+------------+------------------+------------+-----------+--------+-------------------------------------------------------------------------------+---------
 1 | libdvdcss                 | libdvdcss                               | Si         | (r ) Si          | Si         |   99      | rpm-md | http://opensuse-guide.org/repo/openSUSE_Leap_15.0/                            |         
 2 | mozilla                   | mozilla                                 | Si         | (r ) Si          | Si         |   99      | rpm-md | http://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.0/         |         
 3 | openSUSE-Leap-15.0-0      | openSUSE-Leap-15.0-0                    | No         | ----             | ----       |   99      | yast2  | cd:///?devices=/dev/disk/by-id/ata-TSSTcorp_CDDVDW_TS-L633C_R7256GNB212114    |         
 4 | packman                   | packman                                 | Si         | (r ) Si          | Si         |   99      | rpm-md | http://packman.inode.at/suse/openSUSE_Leap_15.0/                              |         
 5 | repo-debug                | openSUSE-Leap-15.0-Debug                | No         | ----             | ----       |   99      | NONE   | http://download.opensuse.org/debug/distribution/leap/15.0/repo/oss/           |         
 6 | repo-debug-non-oss        | openSUSE-Leap-15.0-Debug-Non-Oss        | No         | ----             | ----       |   99      | NONE   | http://download.opensuse.org/debug/distribution/leap/15.0/repo/non-oss/       |         
 7 | repo-debug-update         | openSUSE-Leap-15.0-Update-Debug         | No         | ----             | ----       |   99      | NONE   | http://download.opensuse.org/debug/update/leap/15.0/oss/                      |         
 8 | repo-debug-update-non-oss | openSUSE-Leap-15.0-Update-Debug-Non-Oss | No         | ----             | ----       |   99      | NONE   | http://download.opensuse.org/debug/update/leap/15.0/non-oss/                  |         
 9 | repo-non-oss              | openSUSE-Leap-15.0-Non-Oss              | Si         | (r ) Si          | Si         |   99      | yast2  | http://download.opensuse.org/distribution/leap/15.0/repo/non-oss/             |         
10 | repo-oss                  | openSUSE-Leap-15.0-Oss                  | Si         | (r ) Si          | Si         |   99      | yast2  | http://download.opensuse.org/distribution/leap/15.0/repo/oss/                 |         
11 | repo-source               | openSUSE-Leap-15.0-Source               | No         | ----             | ----       |   99      | NONE   | http://download.opensuse.org/source/distribution/leap/15.0/repo/oss/          |         
12 | repo-source-non-oss       | openSUSE-Leap-15.0-Source-Non-Oss       | No         | ----             | ----       |   99      | NONE   | http://download.opensuse.org/source/distribution/leap/15.0/repo/non-oss/      |         
13 | repo-update               | openSUSE-Leap-15.0-Update               | Si         | (r ) Si          | Si         |   99      | rpm-md | http://download.opensuse.org/update/leap/15.0/oss/                            |         
14 | repo-update-non-oss       | openSUSE-Leap-15.0-Update-Non-Oss       | Si         | (r ) Si          | Si         |   99      | rpm-md | http://download.opensuse.org/update/leap/15.0/non-oss/                        |         
15 | wine                      | wine                                    | Si         | (r ) Si          | Si         |   99      | rpm-md | http://download.opensuse.org/repositories/Emulators:/Wine/openSUSE_Leap_15.0/ |         
user1@linux-cdm8:~>

The way I have been doing system updates in order is:

Apply switch to all repositories individually but Packman:

zypper dup --from <repo_name> --allow-vendor-change

Apply switch to Packman repository only once all others are done:

zypper dup --from packman --allow-vendor-change

Finally update system packages

zypper up

Only exception is Mozilla, which I don’t apply switch since the Firefox-ESR switching since last openSUSE release…

Now, global question would be, can this way be quite correct in general?
Since years ago when I was introduced to openSUSE, I was taught the concept of always leaving Packman repo at last, and before updating general packages, but I was never explained why (I guess because Packman used to break, or still breaks, more packages than other repos?)
Also, is this way still right even when switching repos sometimes downgrade packages?

Finally, I see there are some newer Firefox packages in the Mozilla repo, which are not called “beta” or the like. I know openSUSE by default uses Firefox-ESR, but, is it safe now to use the newer Firefox packages from the Mozilla repo?

Thanks beforehand.

#2

You should be able to just use:

zypper up

for updating. The “zypper dup” was needed when first switching to other repos. But, once that is done, “zypper up” should be sufficient. The vendor-stickiness should take care of updating from the right repo.

Maybe you can occasionally try the switch move to packman – in case a new package has been included in packman. But once every 2-3 months should be sufficient for just checking (unless something is broken and needs that as an immediate fix).

#3

As @nrickert describes,
updating should no longer be a complex exercise.

But,
If you’re concerned about how to address a “bad update” problem,

For the very, very rare occasion when something might happen, if you installed your root partition with BTRFS, become familiar with the simple steps to roll back (snapshots are created automatically before and after every zypper package action, so no need generally to make snapshots manually).

If your root partition is ext4, you may want to install a similar snapshot/rollback capability, extundelete
http://extundelete.sourceforge.net/

TSU

#4

Thanks.

  1. So “zypper dup” is now typically needed just once, or once in a while since installing openSUSE, and afterwards “zypper up” kind of makes the dup thing automatically? From my repos above, consider all have the same 99 priority…

  2. Could it be that leaving Packman at last was also a “thing of the past”?

  3. What about the Mozilla repository? Is it safe now to switch from openSUSE’s ESR version to Mozilla’s mainline?

#5
  1. When you’re moving from one version of openSUSE to another or if you want to make a major change of some sort, the “dup” ie “distribution upgrade” is used. If you had TW installed, a full version is released every few days so “dup” is used, but LEAP releases a new version only every 12-18 months or so… When you want to “update” to acquire relatively minor changes (patches, features, etc) but stay within that openSUSE version, you “update” ie “up”

In other words, although other distros often don’t distinguish between upgrading and updating, we do in openSUSE.

  1. Yes, IMO repository order is now insignificant, and in general even modifying repository priorities can do more harm than good. Vendor and repository stickiness (typically using the --from option) is the recommended way to configure a preference. But, unless you have a specific need, it’s generally best to just follow recommendations and typically allow the Package Maintainers to decide for you when to switch.

  2. Probably depends on your reason for possibly preferring one or the other, and Users post about wanting one or the other periodically.

TSU

#6

Not too long ago, there was a report that the Mozilla repo was broken. I don’t know whether it has been fully fixed. If it is fully fixed, then switching should be fine.

I suppose you could try a switch with “–dry-run” and see what conflicts you run into.

#7

Having been using most types of S.u.S.E/SuSE/openSUSE distros since 1996, I’ve always been partial to YaST’s style of displaying any available updates together with package information, lists of patches applied for bugfixes, SVE number and descriptions of the issues prompting the bugfixes as well as any automatically resolvable dependencies to possibly unwanted, superfluous (looking and you, *-lang packages), locked (»taboo«) or already installed packages. (See this thread from 2013 for further infos and a nice screenshot of the YaST [i]Online Update module.)

Admittedly it’s not for everybody — especially for server environments where automated, pre-tested updates on many machines in parallel are often obligatory, or if you use Tumbleweed where every update is a distro upgrade. But for somebody interested in the dynamics of the software development/-testing/-maintenance processes and how software evolve, how packages depend on each other (and why), what recommendations the dependency solver has for my systems (YaST Online Update, menu »Extras«) which packages may be optional etc., then the YaST Online Update module provides so much more instant information and feedback than zypper does by default… with a bit of eye candy on top.

Updating my Leap installations with YaST Online Update is one of the few exceptions in my otherwise quite xterm-, bash-, ruby- and vim-centric activities. However, I do check manually if any updates are pending with…

zypper lifecycle -v

… about once a day. Cheers!

#8

Too late to correct in original post:

I meant to write »CVE number« (Common Vulnerabilities and Exposures).

#9

Hmm, “zypper lifecycle” does not appear to be documented in the man pages. It seems to report the lifecycle (or end-of-life, end-of-support) information, as the name would suggest.

For occasional checking, I find

zypper lu

to be useful. It lists available updates, without actually installing any of them. And it tells you which repo the updates will come from.

#10

It also runs quite a bit quicker than »zypper lifecycle« (don’t even know how I started using that one; my .bash_history recorded me looking into »/usr/lib/systemd/system/lifecycle-report.service« some time ago.I remember looking at Ruby source code at some level).
I’ll try out both commands side by side in the future — no pending updates this time around. Cheers!

#11 

 > man zypper**<Tab>**
zypper            zypper-lifecycle  zypper-log        zypper-migration
 > man zypper-lifecycle
 >

zypper-lifecycle - products and packages lifecycle information