Best-practice to use newer versions of individual applications on top of Leap?

Hello community,

I have decided to migrate my desktop and laptop system to OpenSuse Leap 15. And while I’ve used Linux for several years now, I’m a newcomer to the OpenSuse ecosystem. Therefore I have a few questions. The first questions is about mixing software sources. First of all, I prefer stable distributions over rolling releases or distros that do releases several times a year. I don’t mind using older packages at all. So, Leap should fit the bill perfectly (and has a lot to offer aside from that). Nevertheless, I’d like to be able to use newer versions of selected (and few) applications on top of a stable desktop environment. Two examples would be Gimp and Darktable, as I do photo editing on a regular basis and sometimes like to be able to use newer features there as well. I know that there are ways to use newer packages in OpenSuse (like the Packman or Open Build Service repositories), but I’m still confused what the best way is or what suits my needs most.

If I opt to use a newer version of a package, says Gimp for example, I would like to be able to do that in a way, that a) keeps the package up to date automatically via the standard package management system, especially in the light of important security updates and b) I would only like to use stable/released versions but not betas, etc. If I check, for example, I can see that there is a newer packaged version of Gimp 2.10 (instead of the officially packed 2.8) available, marked as an experimental package for Leap 15. But how would I ensure to get these newer releases, but not pre-releases from this package, regularily without manually updating it? Can I add a repo for just one packge or limit the use of a repo to that specific package? And what about the dependencies or sub-packages such as gimp-ufraw? Is this possible? What happens if a newer package depends on a newer version of a certain library, but a different package from the base system depends on an older version of the same library?

Thank you!



as you’ve noticed aside from browsers software packages for LEAP only get security and bugfix updates not new versions
new versions can be found in appropriate repositories for your example Gimp can be found in the graphics repo
it’s not an experimental repo but a community repo (I actually think they mixed up the community and experimental links when they redesigned the site) it has the newest package versions including libraries so it’s use is transparent to users and updates are automatic (assuming you’ve added the repo and enabled auto-refresh of it’s content) if a package is in beta or alpha it’s usually stated for example I use Firefox 60 from the Mozilla repo which use to include Firefox-beta as it looks like it was dropped
back to your hypothetical question
if you’d like to use gimp from the graphics repo first you’d need to add the repo

zypper ar -f

when you install gimp you can chose the version from the versions tab in yast or with zypper using the --from alias|name|#|URI switch for example

zypper in gimp --from "Graphics Project (openSUSE_Leap_15.0)"

Graphics Project (openSUSE_Leap_15.0) is the repo name defined in the repo file (you can change the name)
or using the full repo url

zypper in gimp --from

personally I don’t reccomend adding too many extra repo’s as that could lead to unsatisfied dependencies between unrelated packages

Thanks I_A!

I have one follow-up question: Do I understand correctly, that adding the graphics repository by itself does not change any of my installed packages unless I manually select a version/package from that repository in Yast or with zypper (as you explained for Gimp)? Or to put it differently, the package manager will prefer packages from the official Leap 15 repository unless I tell it to fetch a newer version from a community repository? That would be exactly what I had in mind.

I don’t plan to add many newer community packages. So far Gimp is the only package where I’d prefer a newer version than packaged in Leap 15 as the changes from 2.8 to 2.10 are actually quite significant (at least to some users).

That’s correct.

Or to put it differently, the package manager will prefer packages from the official Leap 15 repository unless I tell it to fetch a newer version from a community repository?

That’s not quite the same thing.

Each package has a vendor tag, indicating where it came from. The package manager will not change vendors. So if you already have a package with the vendor-tag for the standard repos, then update will all need to have the same vendor tag until you change that. This usually avoids conflict problems.

I don’t plan to add many newer community packages. So far Gimp is the only package where I’d prefer a newer version than packaged in Leap 15 as the changes from 2.8 to 2.10 are actually quite significant (at least to some users).

There’s one thing to watch here. Gimp probably depends on some other packages (libraries). And if you switch Gimp to a different repo, you might need to switch those other packages to the same repo.

So far, that’s what I meant. But what about if I install a package that I had previously not installed and is available in both repositories? Will the package manager prefer the official Leap repository or the newer community package? Or will it force me to make an explicit choice between the two?

That I figured. Thanks.

I think it will take the first that it finds, unless you explicitly choose. Note, however, that you can assign priorities to repos. A smaller priority number is a higher priority. And it will look in the repo best priority (smallest priority number) first.

If a package is available in more than one repo with the same priority, it will take the package with the highest version (or revision/build count, if the version is the same).

That only applies for repos with the same priority though.
It will always pick the package from the repo with the highest priority (of those that contain the package), regardless of the package versions.

I agree with wolfi completely here, and disagree with what was posted before… Typically nothing more is specified than to simply add the repo, so the highest numbered version (typically latest) will automatically be chosen without regard to the repo. There is no further need to specify a package from that repo unless you’re trying to over-ride default behavior and install an <older> or alternate version.

The other thing to understand is that when you add a repo, this behavior will apply to <all> packages, not just the one application so in this example, if you installed the graphics repo to get the latest version of gimp, any other apps which might also be in the graphics repo will be evaluated the same way.


That only applies for newly installed packages though.
Already installed ones will not be switched to a different repo automatically regardless of how many higher versions (or repos with higher priority) there are, unless you force it.

Don’t know about “zypper patch” but my understanding is that if you run “zypper up” all apps will update to highest number version regardless if they were installed before or after adding the new repo.


afaik zypper up does not do any vendor change and will not switch packages if it finds newer versions in other repo’s only zypper dup does that and only on LEAP (as zypper dup will not do automatic vendor change on TW anymore)
my understanding is that adding a repo does not effect already installed packages and their updates it will only affect future installs so more or less it should be safe
personally I have a few extra repo’s and never had an issue I always run the current stable build ie 13.x 42.x and soon 15.x
the only time I had an issue was when I installed the newest plasma 5 packages from kde:plasma5 which in turn needed the latest Qt5 from kde:Qt5 and the issue I had was with 3rd party apps some lxqt applications refused to run with the latest Qt libraries and that’s one of the reasons I stopped running bleeding edge kde

Actually zypper dup will not do automatic vendor change by default on Leap 15 anymore either.

It is possible to enable automatic vendor change in zypp.conf though (separately for “dup” and “up”), or “force” it by passing “–allow-vendor-change” to zypper.

When doing a zypper up,
zypper <does> do vendor changes and informs you when it happens, and it’s my impression that this is the normal behavior.
Some vendor changes are not done, and based purely on observation and some guessing, those happen when they might be marked as highly experimental and not yet ready for broad use. Different versions of something though, does not usually fall into this category since there can be multiple stable versions of something.


not in my experience and not according to the zypper manual

       update (up) [options] [packagename]...
           Update installed packages with newer versions, where possible.

           This command will not update packages which would require change of package vendor unless the vendor is
           specified in /etc/zypp/vendors.d, or which would require manual resolution of problems with dependencies.
           Such non-installable updates will then be listed in separate section of the summary as "The following
           package updates will NOT be installed:".

Thanks everybody. I think for my use-case you got it all covered.

I ended up adding the repository and assigning it a lower priority. That way, I can select a newer version of a package if I explicitly choose to do so. And the lower priority will ensure that I don’t end up installing other packages from that repository by accident.