Distributions

The proper way to update Tumbleweed

Rolling distributions offer a significant advantage over their release-based brethren. By incorporating new packages as they become available, a rolling distribution can always offer current software while avoiding large, potentially traumatic upgrades. On the other hand, they subject the user to many small, potentially traumatic upgrades. One particular form of pain can come about when significant updates force changes in the set of installed packages. Recent discussions around the proper way to keep openSUSE Tumbleweed current illustrate that a certain amount of confusion exists around rolling-release updates.

Recently, a Tumbleweed user posted that "all hell broke loose" after updating a Tumbleweed system with "zypper dup". That led to a somewhat incredulous response:

A Tumbleweed user might be forgiven for not knowing that they should use that particular command; documentation on the subject is scarce, and questions on the topic abound. Understanding this response requires a brief digression into how openSUSE systems are managed.

The zypper command, which does package management on openSUSE systems, has two commands that can be used to update a system to current software: update (or "up") and dist-upgrade (or "dup"). The former will update existing packages in place but avoids making changes to the set of installed packages or the repositories those packages come from. The latter, instead, will try to track the current state of the distribution by adding or removing packages as needed.

Debian users will note the similarity with the apt-get upgrade and dist-upgrade commands. There, too, users often seem confused about the difference between the two, and it is not uncommon to see advice to the effect that dist-upgrade should be avoided. Trying to maintain a system on Debian testing, which is essentially a rolling distribution, without dist-upgrade tends to lead to updating difficulties over the long run, though.

With regard to zypper, users reading the man page for information about the --no-allow-vendor-change option will find it in a section marked: "Expert Options: Don’t use them unless you know you need them". Said user could probably be excused for shying away from this option, especially since the man page is not particularly detailed in its description of what it does. It is probably fair to say that most openSUSE users don't think of themselves as dealing with "vendors", among other things.

Those users are often accustomed to using unofficial repositories on their systems, though; the set of packages offered by Tumbleweed, while reasonably large, is smaller than those offered by, say, Debian or Fedora, but openSUSE makes it easy for anybody to set up their own repositories in the Open Build System. Hooking into a few of those repositories is often the only way to get all of the desired software installed without undergoing the indignity of building from source.

Use of these repositories can lead to trouble when using zypper dist-upgrade, though. The normal behavior of dist-upgrade is to search every configured repository for the newest version of each package in the system. That can cause a version of a package from one repository to be replaced by another version from a different repository; this change of source repository is the "vendor change" referred to. If a user added an unofficial repository to get one specific package, they may find, years later, that other packages from that repository have pushed aside the versions shipped by openSUSE — versions that the user might rather have kept.

There are two ways to avoid this sort of repository change. One is to use zypper update, which will not make those changes. But, as Richard Brown explained, this approach is not without its disadvantages:

That is why the consensus recommendation for Tumbleweed is to use dist-upgrade with the --no-allow-vendor-change option, regardless of whether one is an expert or not.

Of course, using dist-upgrade has its own challenges, in that it can cause significant changes to the system beyond the in-place updating of packages. But experience shows that this is a necessary evil that comes with tracking a rolling distribution. And, face it, it's also part of the fun and the thrill that comes with running such distributions. The result might be an occasional surprise, but the best thing to do is to just roll with it.

Comments (11 posted)

Distribution quotes of the week

— Lucas Nussbaum

— Chris Lamb

— Russ Allbery

— Stephen J Smoogen

Comments (none posted)

The end of the line for EPEL-5

The remaining users of RHEL 5 (and derivatives) will want to know that maintenance of the EPEL-5 repository is coming to an end. "In the end, EPEL-5 went live sometime in April of 2007 and over the next 10 years grew to a repository of over 5000 source packages and 200,000 unique ip addresses checking in per day at its peak of 240,000 in early 2013. While every package built for EPEL is done with the RHEL packages, all of these packages have been useful for the various community rebuilds (CentOS, Scientific Linux, Amazon Linux) of RHEL. This meant that growth in those eco-systems brought more users into using EPEL and helping on packaging as later RHEL releases came out. However as these newer releases and rebuilds grew in usage, the number of EPEL-5 users has gradually fallen to around 160,000 unique ip addresses per day. Also over that time, the number of packages supported by developers has fallen and the repository has shrunk in size to 2000 source packages."

Comments (none posted)

Red Hat Enterprise Linux 6.9 released

Red Hat has announced the release of Red Hat Enterprise Linux 6.9. "Red Hat Enterprise Linux 6.9 delivers new hardware support developed in collaboration with Red Hat partners which helps to provide a smooth transition of Red Hat Enterprise Linux 6 production deployments to Red Hat Enterprise Linux 7 environments. Additionally, Red Hat Enterprise Linux 6.9 adds updates to TLS 1.2 to further enhance secure communications and provide broader support for the latest PCI-DSS standards, better equipping enterprises to offer more secure online transactions."

Comments (none posted)

Qubes announces the Xen Security Advisory (XSA) Tracker

Qubes has announced its new Xen Security Advisory (XSA) Tracker, which clearly shows if Qubes is (or was) affected by any given XSA. "It's worth noting that Qubes has typically not been affected by new XSAs. At present, it has been over six years since the first XSA was published on March 14, 2011. Since that time, 203 XSAs have been published (excluding unused XSA numbers and currently embargoed XSAs). However, only 17 (8.37%) of these XSAs have affected the security of Qubes OS. These statistics will continue to be updated on the tracker page as new XSAs are published."

Full Story (comments: none)

Advanced discontinuation notice for openSUSE Leap 42.1

OpenSUSE has announced that openSUSE Leap 42.1 will reach its end of life on May 16, 2017. "Note that the openSUSE Leap 42 class of distributions is designed to be easily upgradable within minor versions, so Leap 42.1 to Leap 42.2 update should be easy and [seamless]."

Full Story (comments: none)

Ubuntu: A follow-up on 32-bit powerpc architecture

Ubuntu has discontinued support for the 32-bit powerpc architecture in Zesty Zappus (17.04). "We are well into Feature Freeze at this point, so an update is overdue. As of Feature Freeze in February, the status is that powerpc packages are no longer considered for proposed-migration, and we have discontinued all CD image builds for powerpc in zesty. For the moment, uploads continue to be built for powerpc in Launchpad, and packages are still published in the archive. You should expect both to be discontinued before the 17.04 release."

Full Story (comments: 17)

Distribution newsletters

• DistroWatch Weekly (March 20)
• Last couple of weeks at LineageOS (March 20)
• Lunar Linux weekly news (March 17)
• Mageia weekly roundup (March 17)
• openSUSE Tumbleweed Review of the week (March 19)
• This Week In Solus (March 19)

Comments (none posted)

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

The Android Developers Blog introduces the first developer preview of Android O. This version includes background limits, notification channels, autofill APIs, PIP for handsets, font resources in XML, adaptive icons, and much more. "Building on the work we began in Nougat, Android O puts a big priority on improving a user's battery life and the device's interactive performance. To make this possible, we've put additional automatic limits on what apps can do in the background, in three main areas: implicit broadcasts, background services, and location updates. These changes will make it easier to create apps that have minimal impact on a user's device and battery. Background limits represent a significant change in Android, so we want every developer to get familiar with them."

Comments (22 posted)