Why isn’t all software always the very latest version?
There are a couple of elements to this question.
-
Software which has just been released by the upstream project needs time to be packaged and built, so there will always be some time before it becomes available in a packaged format. If a package has patches, then more time will be needed to check whether the patches are still needed and, if so, re-written to apply against the new version. Compiling software from its source code can take a long time.
-
Most Manjaro packages are taken from Arch, and Arch packages also have to go through a process from being built, to their stable branch, before reaching our branches:
Packaging
Arch staging
Arch testing
Arch stable
Manjaro unstable
Manjaro testing
Manjaro stableSome packages can be rebuilt outside of this process, generally for security updates, but they still require time to be built. For instance Chromium will take around six hours to compile (if it succeeds on the first attempt)!
Copied and reformatted from the archived forum, by @jonathon and @c00ter.
The package is up-to-date in AUR. Why can’t i get that version?
Some AUR packages are also in Manjaro’s repositories. In such cases, the repositories will have precedence over AUR when you try to update them, thus preventing you from getting the latest version immediately.
How can i get that latest version?
There are several options available for getting a newer version of packages.
Wait for the next update
Difficulty: ☆☆☆☆☆
Obviously, the basic recommendation is still to wait for the update to come to your current branch.
You can follow the package’s version on the various branches there: https://manjaro.org/branch-compare/
Switch to a self-contained version
Difficulty: ★★☆☆☆
Self-contained packages have several advantages in our case:
- They are usually made by the developers themselves whenever they release a new version of their application. A new version is thus usually available earlier than in the repositories.
- They ship with their dependencies, and thus do not rely on system-installed ones, theoretically removing the risk of incompatibility.
Those benefits are still to ponder against a few drawbacks. Please refer to the related documentation for details:
Please refer to the following guides for enabling the self-contained package manager of your choice:
Switch to an upper branch
Difficulty: ★★★☆☆
Switching to the testing or unstable branch allows you to get updates earlier.
Attention! There are several things to take into account when switching branches:
- As updates come earlier, so do potential bugs. Since those branches serve to test the stability of packages before they reach the stable branch, they are obviously more prone to issues.
-
We would be very grateful if you can then contribute, by signaling in the related Update announcement any issue you find:
-
- As partial updates aren’t any more supported on those branches than on the stable branch, it is recommended to do a full update, rather than update only the selected packages.
Please refer to the following guide for switching branches: Switching Branches - Manjaro
Switch to a development version
Difficulty: ★★★★☆
Some packages have a development version available from AUR, identifiable with the -git suffix. You can install those in place of the “standard version” package in order to have the latest development build available.
Attention! There are several things to take into account when using a development package version:
- Development packages usually do not change version with new commit from the developers. Instead, the version for that package very often simply refer to the build process version. This means those packages are not the updated the same way.
- When using CLI package managers, the
--develoption is usually to be used in order to detect changes to the source, and thus allows to rebuild the package using the latest version. - In pamac, you may enable “Check for development packages updates” in the settings.
- When using CLI package managers, the
- Development version is even more bleeding-edge than what is usually in the repositories, as they use a development state before release. You are then very dependent to the developers’ quality in coding.
-
The developers would be grateful if you can then contribute, by signaling them any issue you find.
-
- Likewise, using a development version usually places you way ahead of the repositories in term of dependency alignment, which can also be source of instability.
For those reasons, using development versions is not recommended, moreso for core packages, unless you are confident with your debugging skills.
