3rd party packages

There are some software packages which are not available in the tumbleweed repos. I understand that all distributions universally recommend against installing outside the provided repos. But its unavoidable. They are either impossible or difficult to replace for my use case.

Below is what I anticipate being the order of preference for non-repo installs. Is it correct? Am I missing something?

Overall I would like to have the system package manager at least know about non-OpenSUSE packages existing and ideally look for updates. Is it possible? Some sort of local, custom repo? Or is there some other consolidation strategy?

alternative repos

benefits: still managed by usual system package manager. will find updates.

problems: It seems like there is only a couple and other than the xfce4 repo they don’t have much I am interested in.


I don’t use this prior so all questions.

Some are available for download as rpms which could be installed with zypper install. The documentation warns against installing rpms targeted at other distros. Are there generic rpms or should I assume any rpm which does not mention TW is incompatible?

I am also seeing some projects provide instructions on how to build an rpm from source. Is there a benefit to this?

Do yum, dnf or other rpm package managers available do anything special/different compared to zypper so far as 3rd party packages go? Or are they just different ways to interface with the same underlying system?

Is there a way to automatically check for updates for packages installed via rpms, or does it require manual checking and replacing by the user?

language/platform-based package manager

examples: pip/pipx, cargo, npm, basher

benefits: updates can usually be handled by the parent application if you remember to run them.

In the past when I was running a system with very limited set of packages from the vendor, I relied on a patchwork of such installation methods. It was somewhat functional but really not great for long term use.


Everything I want to use can be built/run from source typically obtain from a git repo.

problems: all kinds of dependency issues. You end up with a bunch of dev packages on the system, which can cause conflicts.
Updates must be done manually.

I read Review of the week 2024/08 about python 3.9 deprecation and I wonder what if anything this would mean for pip/pipx packages. Python versions have been a problem on every system I’ve run but the impact varies.

portable formats

And then there is AppImage and flatpak. Have not used them much.

Benefits: IIRC AppImages can check themselves for updates when run.

Problems: Seem to be quite resource intensive.

open build service

I do not understand if this is relevant or not. Documentation for end users is very thin. Using the web interface I searched for packages and don’t find anything extra available here. I mistakenly thought in one instance I did and attempted to add the OBS repo per instruction in the results but the repo was unfindable. Is this active and if so, is there any reason to use it?

A related question
A couple of packages are in the repos, but they do not install due to missing dependencies. How do I handle this?

1 Like

Flatpaks are resource (storage and network bandwidth for install/update) intensive.
Yet I have some installed: spotify and other small stuff that are not packaged for distros by the developer.

Distrobox containers are where I test & install most of the packages that are not in TW repos.

hmm that’s interesting. Is it resource intensive to run a whole second OS? Makes sense for testing if you are a developer, or you have occasional and brief needs for a particular package. Could be worth the tradeoff. But is it practical to use on a day to day basis?

Not very resource intensive to run a container optimized OS. Needs less than 50M per container depending on the image. I have a full fat debian one with systemd/init and close to 600 packages that idles at 75M with Mullvad daemon running in the background.
Of course that shoots upwards of 500M with a browser open within the container.

Flatpaks are mini containers themselves (depending on how you look at rpm-ostree) but their problem is that each app can target a specific runtime and ships with their own set of libraries. So at any point in time, you may be running several different runtimes of Gnome, KDE plus the libraries shipped by the app.

Apps installed via distrobox uses the same shared libs and runtimes available in that container image/OS. Much more efficient! :slightly_smiling_face:

Oh that is cool! I have 50mb to spare. I would only need 1 instance running.

Fair enough with a browser. Firefox is a beast, at least the way I run it. So it’s to be expected.

If it works as promised, this would take care of the “absolutely required” section of my outstanding packages.

Some of the missing packages are those which manipulate windows, catch input, and other tasks that would seem to be unsuitable to a solution like this. It seems like there would be some degree of latency which would become bothersome. You agree?

Those are replaceable of course, I just have everything set up with the framiliar packages.

Where did you look for?
Try searching at
it looks at some 100 available repos that you can also browse here
and if the law in your country allows that you can even find non-free / patented packages at Packman
Please be aware that installing packages via those sources is not always like installing from “official” repos, since the degree of testing and compatibility is not the same and not all repos deserve the same level of “trust”.
But if you are looking for automatic updates via zypper that is the way to go.
Keep asking here if you need help with specific packages.

I found a link to the search page via Portal:Build Service but like I said it is unclear to me what is going on with the OBS.

None of the missing packages I searched for were found here. Entering very general keywords I find mostly duplication as to what is available in the main repo or the few alternative repos which are suggested in official documentation.

I did try installing from here. It offers 3 non-repo methods to install software which I skipped for now. Eventually if you are persistent you can find instruction for how to add the repo directly, but it doesn’t work:

 zypper addrepo https://download.opensuse.org/repositories/openSUSE:Factory/standard/openSUSE:Factory.repo
File '/repositories/openSUSE:Factory/standard/openSUSE:Factory.repo' not found on medium 'https://download.opensuse.org/'
Abort, retry, ignore? [a/r/i/...? shows all options] (a):

which lead me to wonder as to the status of this project.

Thanks for explaining to me at least how I can see a list of what composes this search.

I looked through those too… Packman seems mostly to be codecs, drivers and the like, no? I haven’t tried any multimedia stuff yet so I don’t know how or if it’ll work out of the box. But it’s good to know where to look if needed.

Is the link you provided correct? In my bookmarks I have a different one. I came across the URL you shared but thought it’s probably out of date due to no https. The documentation links to both. Are they equivalent?

NEVER add a factory repo to Leap or Tumbleweed unless you are a developer with deep knowledge. You will break your system within seconds by doing this…
Factory is the raw developement codebase, which is rarely tested and for sure will break the system of unexperienced users…


Apparently you are confusing the development areas in OBS and the actual repositories holding rpm packages for download. For instance:
is the generic home page for Packman
is the development area within OBS where you can track project status and the like
is the actual repo (well, the main available mirror) from which zypper can download packages.
Please read again carefully the documentation with its “zypper ar” examples.
For instance, if I want to add the Wine repo to my list I would issue:

LT-B:~ # zypper ar http://download.opensuse.org/repositories/Emulators:/Wine/openSUSE_Tumbleweed/ Wine
Adding repository 'Wine' .....................................................................................................[done]
Repository 'Wine' successfully added

URI         : http://download.opensuse.org/repositories/Emulators:/Wine/openSUSE_Tumbleweed/
Enabled     : Yes
GPG Check   : Yes
Autorefresh : No
Priority    : 99 (default priority)

Repository priorities in effect:                                                                    (See 'zypper lr -P' for details)
      98 (raised priority)  :  1 repository
      99 (default priority) :  4 repositories
LT-B:~ #

Posting a few examples of what packages you are looking for might help us give detailed suggestions.

While that might be a good advice generally speaking, the OP is trying to reach an outdated address that actually aliases to the main Tumbleweed OSS repo with actual /repodata/ but of course with no openSUSE:Factory.repo file.

I got that line by searching for ksnip. Which is available in yast2 but doesn’t install due to a dependency issue-- not likely to be solved this way but it was the only thing I could find here that I wanted to install. This is the result page. Clicking “Appstream” is a flatpak which I would like to avoid. So I clicked “expert download” which goes to Install package openSUSE:Factory / ksnip where finally instructions to add a repository are found and then are as I copy/pasted above.

Here is a screenshot:

It sounds like what you are saying is that I should find out somehow (???) what repository ksnip is in and add the specific repo similar to your example. That sounds more reasonable than adding the whole kitnaboodle. Maybe a websearch would find it or something.

Re Packman I got the links from this page: Additional package repositories - openSUSE Wiki:

I assumed the other link was outdated because of non-https. But you are saying this is actually the correct URL. Why in 2024 would http be the choice? Especially for something where the very first thing you say about it is that it is illegal in some places. With only some vague information available as to the details of that.

I am definitely confused.

So there is a repo which could theoretically be managed by yast/zypper, but it either can’t or shouldn’t be used.

This are again basics. Most linux distributions still use http mirrors as there is no data transfered which needs an additional transport security layer. The integrety of downloaded packages is verified via checksums and gpg signatures.

1 Like

There is no latency like with a VM, distrobox has incredible host integration and hooks the container directly into the host’s Wayland, X11, and Pipewire sockets, and all HID devices are passed through. Of course this means there is no security/boundary layer often associated with containers. Install in the container only trusted packages that you would normally install on the host but cannot because your host OS doesn’t have the packages or require so many dependencies/build tools that you would rather not clutter up the host with those packages.

1 Like

lots of distros have https available. and where there is http repos, the web interface is usually/always https because it is a standard and expected layer of security.

of course there is security needed if you are distributing potentially illegal software. there is no way to find out about the legalities of a specific package in a specific jurisdiction. so it seems awfully irresponsible to avoid the use a widely used technology. why?

since trying to get my head around tumbleweed I have had more “no https available” notifications than in the past several months put together. there are all kinds of http-only resources and expired certificates all over the place. it does not really inspire confidence.

Hmm, I think it’s possible to use repo priorities as explained in this video together with allowing the solver to change vendor automatically to have a stable system. I think it was @karlmistelberger (thanks!) who recommended it first to me.

Makes sense TBF, you start with packages not in official repos and they’re automatically installed from Factory, but when those same packages have trickled down to official repos, zypper would automatically grab the stable ones as the Factory repos have lower priority.

That is an unlucky example.
The package is available in the standard OSS repo and would be installable simply by:

zypper in ksnip

if it weren’t for the dependency issue you mention; I’m not familiar with KDE development so cannot comment on why that happens.
The address you found for the repo is outdated and likely nobody cared to update to the standard OSS repo where in fact “zypper in” finds it. Likely nobody is using that link since the standard install finds the package.
There is another build in the X11:LXQt:Other repo, which can be added by zypper via:

zypper addrepo https://download.opensuse.org/repositories/X11:LXQt:Other/openSUSE_Tumbleweed/X11:LXQt:Other.repo

but it still needs that libkImageAnnotator.so.0()(64bit) dependency that cannot be satisfied, so it is a no-go as well.
I wonder if ksnip is an obsolete / abandoned package?

When you look at “community” repos you are in charge of deciding if you can or should use them. That includes legal reasons (not all legal systems are the same and OpenSuse distributes worldwide, so restricts to packages that are ok in all jurisdictions), kind of system (it is ok to install unstable packages in a development system, it is generally unwise to do so in a production system) and experience / skill level of users and their ability to recover from a damaged system.
As always on Linux you can do everything if you know what you are doing and the decision is up to you.

I see that there is a ksnip build by Eric Schirra ecsos that is actually installable after adding his home repo via:

zypper addrepo https://download.opensuse.org/repositories/home:ecsos/openSUSE_Tumbleweed/home:ecsos.repo

I don’t know Eric and I provide this info for reference only; I didn’t check if the package works either (I don’t regularly use KDE).
It is entirely up to you to choose if you can trust that build or not, since installing builds from people you don’t know and trust is not advised generally speaking.

My advice is to include a good alias parameter to a zypper arstatement. It will make identifying and using the repo much easier.

Repos are NOT managed by YaST > Software or zypper. YaST > Software and zypper can be used to get packages from repos. The repo owner manages the repo (we all hope).

Repos are like shops. And your feet allow you to go shopping into all of them (and no, your feet do not manage the shops). But if it is wise to enter some shops is completely up to you.

1 Like

Good advice, generally, but in this case the home:ecsos.repo file provided its own “ecsos’s Home Project (openSUSE_Tumbleweed)” alias.