Installing Packman Codecs

Several posts describe the installation of packman codecs. Most of these recommend the installation of a lengthy list of packages. Actually this is not needed for upgrading codecs. Adding the packman repo and switching to will do the trick. Run the following commands in a root shell before installing new multimedia software:

Leap 15.2

zypper addrepo --refresh --priority 90 packman
zypper **dist-upgrade** --allow-vendor-change --allow-downgrade --from packman


zypper addrepo --refresh --priority 90 packman
zypper **dist-upgrade** --allow-vendor-change --allow-downgrade --from packman

From now on new installs will work without repeating the above switch of repos. zypper will select the proper version automatically. When selecting your mirror consult: See also:

As far as my experience goes, this (or similar using YaST) is indeed enough. I always wondered why that lengthy list of packages to be installed is given.

Glad that you have the same (and as far as I know you, also long time) experience.

I will suggest one change. Make that first line:

zypper addrepo --refresh --priority 90 '$releasever/' packman

That puts $releasever in the URI, for easier future upgrades. Note that the ‘quotes’ are mandatory, so that the shell is not confused by the ‘$’.

There isn’t a corresponding change for Tumbleweed.

Depends on, how much of Packman the user wishes to use:

  • All of Packman;
  • Packman Essentials
    : “provides codecs and audio and video player applications, to fulfil the most essential needs”; - Packman Multimedia
    : “contains many more multimedia related applications”; - Packman Extra
    : “additional non multimedia related applications, mostly network related”; - Packman Games
    : “obviously, games”.


I would say that @Karlmistelbergers Howto works simply for all. And I assume that is why he wrote this.
This is not for those who want to spare a few bits/pieces/seconds on a repo refresh.

I tend to “use Packman but, only for what I really need to (use).” – for my use case, I only use Packman for things which have licensing issues, such as the codecs Firefox needs to sensibly deal with public service broadcasting web sites …

  • I pay a license fee and therefore also want to be able view and hear their web offerings – not only what they broadcast to radio and television receivers …
  • Therefore my personal restriction to only use that part of Packman which satisfies my needs …

It is completely clear to me that this Howto was not intended for people like you, but for the beginners that want their multi-media running ASAP without much fuss.

Deleted packman, copied the above, pasted into a root shell and verified by running dist-upgrade again.

Being consistent has enormous benefits over “It works for me” and “It works now”. This translates into “It will not work with other setups” and “it will fail when maintaining the system”.

Just to confirm: The original post is meant to provide a minimal solution for upgrading the codecs. Newbies are advised to perform the upgrade immediately after installation and to verify multimedia applications are working correctly before starting further tinkering.

Yes, and with my suggested change it does that very well. I do like your use of “–priority” in that “addrepo” command. And I like that you used the long form of the command and options, because that is more explanatory for new users.

In my experience, you do not need to separately add “essentials”, “extra” etc as separate repos. If you add the main packman repo, as suggested at the top of this thread, you already have access to those. It becomes a matter of what packages you install with Yast or other package manager.

I have the same view. (KISS principle.)

May need to add that, the string value of “releasever” has to be retrieved from “VERSION_ID” in “/etc/os-release”.

identifying the operating system version, excluding any OS name information or release code name, and suitable for processing by scripts or usage in generated filenames.

«man 5 os-release»

According to the zypper man page:

The value [of $releasever] is obtained from the /product/version XML-node in /etc/products.d/baseproduct.

We’re talking about Codecs which are only available in Packman – because of licensing …
[HR][/HR]Case: «Having to install Codecs because Firefox cannot play HTML5 videos»

  • A common case when viewing current visual media offered on the Internet – with Windows, Apple and a mobile telephone, everything is fine – with openSUSE, not.

Using the “watering can method” applied to Packman, often means that, for the case of new users this can easily lead to problems – please read posts in this Forum related to “I installed something and now nothing works” …

The packages required to enable HTML5 videos when using the ESR Firefox delivered with openSUSE are:libavcodec56, libavcodec57, libavcodec58, libavformat56, libavformat57, libavformat58, libavdevice56, libavdevice57, libavdevice58.

The following are “Packman only”: libavcodec56, libavformat56 and libavdevice56.
The rest are in openSUSE OSS and Update repositories (restricted licensing) and, Packman (full functionality).

Whether or not the “complete capabilities” «regardless of licensing» packages will be installed due to “required” dependencies depends on the packages which need the FFmpeg codec, device and stream format libraries.

  • Which is currently not the case for the FFmpeg version 56 and 58 device libraries – nothing requires the things …

[HR][/HR]So, remaining with the “new to openSUSE and want to view current video offerings via Internet just like my mobile telephone and/or Windows/Apple machine does” case:

  • The simple thing to do is, to restrict the access to the Packman repositories to only that area where Codecs are stored:
zypper ar -cfp 90 packman-essentials

«The extra characters required are 2 times “Essentials … »

  • And, to recommend that only the needed Codec packages (with license issues) are to be installed – and, nothing else …

zypper install --from packman-essentials --force libavcodec56 libavcodec57 libavcodec58 libavformat56 libavformat57 libavformat58 libavdevice56 libavdevice57 libavdevice58


  • AFAIK, audio codec licensing issues are few are far between – video editors may require “Essentials” codecs …

Is there, really, any other “need codecs with licensing issues” case for “new to openSUSE” users?

I’m not quite sure what you mean by “watering can method”, but we can let that pass. Somehow you seem to think it important to limit packman to Essentials. If that’s what you want, then fine.

I always add the full packman repo. I do not add the other packman repos (Essentials, Extra, Multimedia), because they are included in the full repo.

Personally, I have never run into “I installed something and now nothing works” problems. Yes, there are many threads with such problems, but I do not recall that any of those threads were due to using the full packman. To the best of my memory, they were all due to using other repos (neither packman nor openSUSE), or occasionally due to use an openSUSE extra repo but improperly mixing (not doing a full repo switch).

Looking at what I have currently have installed from packman, it looks as if almost all installed packages are from Essentials, with the one exception of “autopano-sift-C”. And I’m not sure that I have ever used that package, but something pulled it in.

With Leap 15.1, I also installed “vivaldi” from packman, and I think that came from the packman Extras. At present, “vivaldi” does not seem to be available in packman for Leap 15.2, so I don’t have it installed.

My practice:

1: Configure the full packman repo;
2: Give packman a higher priority (lower priority number), so that it is preferred for new packages;
3: Do the repo switch (switch system packages to packman);

I sometimes repeat the repo switch. It seems that some updates pull in additional packages, and sometimes those have a better version in packman, which a repeated repo switch can take care of.

As for other repos: I have the kernels repo configured but disabled. I can temporarily enable if I want to experiment with a newer kernel. I have the mozilla repo

configured but disabled. That’s mostly in case I decide to switch to the latest “firefox” instead of the released version. The “libdvdcss” repo did not seem to be available yet for Leap 15.2, so I’m doing without that one package for now.

Ahh! Yes!!! But, because the variable name “releasever” is followed by the character “/”, it has to be enclosed in curly braces:

zypper addrepo --refresh --priority 90 '${releasever}/' packman

And, on a bash CLI, the single quotes can be done away with provided that, the “$” is escaped with a “\”.

  • The “\” escape character may be needed in scripts as well but, I haven’t tested that …

This thread applies strictly to current Leap 15.2 and Tumbleweed.

When preparing for the top post I switched the current version of Tumbleweed to repo oss and deleted any remnants related to packman.

I tested the following procedure on Tumbleweed:

zypper addrepo --refresh --priority 90
zypper **dist-upgrade** --allow-vendor-change --allow-downgrade --from packman

Then I installed Leap 15.2 and tested the following:

zypper addrepo --refresh --priority 90 '$releasever/' packman
zypper **dist-upgrade** --allow-vendor-change --allow-downgrade --from packman

I reiterate the recommendation:

Newbies are advised to perform the upgrade immediately after installation and to verify multimedia applications are working correctly before starting further tinkering.

No, no and no again!

The text


is something to be interpreted by zypper, not by the shell. Thus it is escaped (together with the whole argument)


Henk, you’re negating the content of the zypper man page – “releasever” is a Zypper internal variable:

  Remember to protect the $ when using these variables on a shell command line:
       zypper ar -f\$releasever packman
   If a variable is followed by an alphanumeric character or underscore it needs to be enclosed in {}:
       zypper ar -f\${releasever}_packman

Yes, it’s also needed in (Bash) shell scripts.

  • The Zypper folks seem to have implemented and documented a solution which uses a syntax which doesn’t use single quotes …