Here are some notes I wrote for myself concerning tumbleweed snapshots. I’m posting them here in case they may be of use to others. It represents the minimum amount of info I need to reference in order to manage tumbleweed snapshots on my desktop. The potential audience is probably best described as any experienced Linux/UNIX admin who’s used to a fair bit of DIY under the hood.
**Tumbleweed snapshots introduction
**
Tumbleweed-snapshots is a layer of repo management software and an associated history of official-release snapshots that logically sits above the normal tumbleweed official-release repo. The name tumbleweed-snapshots is a little confusing because it overloads the meaning of two existing terms: tumbleweed, and snapshot, just remember tumbleweed-snapshots is a separate repo system.
The tumbleweed-snapshots components are as follows:
-
Tumbleweed-snapshots history site
: a mirror of recent official snapshots http://download.opensuse.org/history/ - Tumbleweed-snapshots quality review website
: http://review.tumbleweed.boombatower.com/ - tumbleweed-cli
: the package that installs the tumbleweed command for managing the installation of tumbleweed-snapshots. - Official openSUSE Tumbleweed release
: source of releases mirrored to the history site.
The advantage of tumbleweed-snapshots is that it provides the facility for you to choose any recent official-snapshot as the basis for your tumbleweed installation. This allows you to stand back from the official bleeding edge by choosing safer releases. It also enables you to wait out periods of instability. The quality of the Official Releases held with the tumbleweed-snapshots can be reviewed by consulting the related openSUSE Tumbleweed Review website which posts a number of metrics.
Switching to the tumbleweed releases repositories
The tumbleweed-cli package installs the tumbleweed command which is used to manage a installation that uses tumbleweed-snapshots. The package is part of the standard tumbleweed distribution and can be installed by yast or zypper (which ever you prefer).
In order to use the tumbleweed-snapshot repos you need use the tumbleweed command to update your systems repos to point to the history site, this is accomplished by the init command:
tumbleweed init
The init changes all the repo URL’s in /etc/zypp/repo.d/ that with begin with a reference to
http://download.opensuse.org/tumbleweed/
to now be a reference to the snapshot history repos and includes a variable that will resolve to the snapshotVersion to actually use:
http://download.opensuse.org/history/$snapshotVersion/...
The value of snapshotVersion is written to
/etc/zypp/vars.d/snapshotVersion
Here’s the content of my current snapshotVersion file:
20181204
The init command also changes the local name of the repo in /etc/zypp/repos.d/*.repo to include the date of the snapshot used for the initial init. Here’s the content of my current /etc/zypp/repos.d/repo-oss.repo
[repo-oss]
name=repo-oss (20180917)
enabled=1
autorefresh=1
baseurl=http://download.opensuse.org/history/$snapshotVersion/tumbleweed/repo/oss
type=rpm-md
keeppackages=0
Note, the edit of the name field change is a one time thing done at init. Confusingly the name field in .repo won’t be updated if you use further commands to switch to different snapshots. So don’t worry if some of the feedback continues to refer to the original init snapshot date, even when you set it to a different one (the actual snapshot used is always the one listed in /etc/zypp/vars.d/snapshotVersion).
After updating the repo’s you can then proceed to use the tumbleweed command to install any of the available tumbleweed-snapshots listed at the review website.
**Managing tumbleweed-snapshots
**
After reviewing the history of snapshots at http://review.tumbleweed.boombatower.com/ , you can switch to a desired snapshot by issuing a tumbleweed switch command, for example:
tumbleweed switch 20181208
The switch command sets the target for the next zypper ref and zypper dup by updating /etc/zypp/vars.d/snapshotVersion. Aside from this change, nothing is actually done until you manually do a refresh and distribution-upgrade, for example:
zypper ref
zypper dup
You can combine the switch, ref, and dup steps by using the –install option with the switch, for example:
tumbleweed switch --install 20181208
If you decide to abandon a switch before the install, you can revert the target version by issuing a revert command. Check whether the target is the correct by using tumbleweed status, for example:
tumbleweed status
latest : 20181224
target : 20181208
installed: 20181204
Revert to the desired/correct version by using tumbleweed revert, for example:
tumbleweed revert 20181204
tumbleweed status
latest : 20181224
target : 20181204
installed: 20181204
If you actually completed and installed a switch, you can revert both the switch and install by using –install option with a revert, for example:
tumbleweed status
latest : 20181224
target : 20181208
installed: 20181208
tumbleweed revert --install 20181204
Revert –install is equivalent of:
tumbleweed revert 20181204
zypper ref
zypper dup
The main difference between switch and revert is that each option attempts to correctly update the history of what has been switched and reverted. The history can be seen with:
tumbleweed history
As far as I can tell, there doesn’t appear to be any technical implications if the history is incorrectly updated by using switch instead of update.
Tumbleweed stability score
The Tumbleweed Review website: http://review.tumbleweed.boombatower.com/ scores each official release. The scoring is done by some python code available here:
See: https://github.com/boombatower/tumbleweed-review/blob/master/src/score.py
Without going into detail the score is roughly computed as follows
score = 100 - ( bugs + emails + snapshot_score )
where
-
bugs
is number of reported bugs / 10 - emails
the number of thread references truncated to within the limits 3 to 25. - snapshot_score
is a complicated counting/weighting of kernel and Mesa changes.
A good score would result if there were few reported bugs, not much email, and the kernel or Mesa were not heavily modified.
Releases status is determined by examining the score and release date according to the following short-circuit logic:
- Pending: today - releaseDate < 7
- Stable: score > 90
- Moderate: score > 70
- Unstable: otherwise
**External dependencies
**
I use a few other repos outside the tumbleweed-snapshot system such as packman. I sometimes find that my tumbleweed-snapshot dependencies can be out of alignment with these external repos. This raises dependency conflicts which I normally resolving by:
- electing not to update a package,
- electing to upgrade a package ignoring dependency breakages,
- or by waiting a few days in which case the problem may go away.
Of course, such conflicts might be due to official tumbleweed changes, and not the fault of tumbleweed-snapshots.