Rpmfusion-free-updates | libheif-freeworld and libheif | version conflict

 Problem: package libheif-freeworld-1.15.1-5.fc37.x86_64 requires libheif(x86-64) = 1.15.1, but none of the providers can be installed
  - cannot install both libheif-1.15.2-1.fc37.x86_64 and libheif-1.15.1-2.fc37.x86_64
  - cannot install the best update candidate for package libheif-freeworld-1.15.1-5.fc37.x86_64
  - cannot install the best update candidate for package libheif-1.15.1-2.fc37.x86_64
 Package                     Architecture               Version                             Repository                   Size
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 libheif                     x86_64                     1.15.2-1.fc37                       updates                     258 k

Try to remove libheif would end up in several programs to be removed. Can updates from rpmfusion-free-updates not be hidden back when such a inconsistency exists ? Where would i have to request that?

sudo dnf remove libheif
Dependencies resolved.
 Package                        Architecture        Version                        Repository                            Size
 libheif                        x86_64              1.15.1-2.fc37                  @updates                             671 k
Removing dependent packages:
 gimp                           x86_64              2:2.10.34-1.fc37               @updates                             105 M
Removing unused dependencies:
 gimp-libs                      x86_64              2:2.10.34-1.fc37               @updates                             1.8 M
 libheif-freeworld              x86_64              1.15.1-5.fc37                  @rpmfusion-free-updates              112 k
 libmng                         x86_64              2.0.3-16.fc37                  @fedora                              543 k
 libmypaint                     x86_64              1.6.1-7.fc37                   @fedora                              911 k
 libwmf                         x86_64              0.2.12-9.fc37                  @fedora                              425 k
 mypaint-brushes                noarch              1.3.1-6.fc37                   @fedora                              2.3 M
 pygobject2                     x86_64              2.28.7-16.fc37                 @fedora                              926 k
 pygtk2                         x86_64              2.24.0-37.fc37                 @fedora                              4.0 M
 python2-cairo                  x86_64              1.18.2-12.fc37                 @fedora                              320 k
 python2.7                      x86_64              2.7.18-26.fc37                 @updates                              57 M
 tix                            x86_64              1:8.4.3-34.fc37                @fedora                              1.0 M

Last metadata expiration check: 2:03:25 ago on dom 07 mai 2023 09:59:07.
Dependencies resolved.

I’m not sure if I understand the goal here. But it should be possible to remove the libheif-freeworld package, as far as I know it’s only a weak dependency and can be removed as such. It looks at first glance that your problem is not libheif but libheif-freeworld. This might be helpful for related actions: Weak Dependencies Policy :: Fedora Docs

Additionally, to solve the error that is the origin of all that, maybe these two posts help to inform the responsible maintainer to get this solved in the database:

You can complement that by writing an email to the devel mailing list (which led to this the last time : ). Maybe someone has already filed it.

I’m wondering if there are currently some organizational issues around libheif.

Also https://bugzilla.rpmfusion.org/show_bug.cgi?id=6670

Bugzilla – Bug 6670 RPMFusion libheif-freeworld blocks Fedora upgrade of libheif (1.15.2-1.fc38)

Cool. Then it seems you just have to wait. However, with regards to the comments in the ticket, I think that conflicts should not be “accepted” as something normal or even intended when dependent packages are to be updated. It seems that the two packages have a dependency but their maintenance is not synced.

So you can wait for the update (my reading of the maintainer’s comment is that this could happen again), or remove the rpmfusion-sided libheif-freeworld if you do not need it (which you can simply test).

Just to be sure that you know: you can do all updates except the libheif update if you use the option --exclude=libheif (e.g., dnf update --exclude=libheif). So this is not a blocker for updates in general. You can use the exclude option until the libheif-freeworld package has been updated and is synced to libheif (the same in future).

This is true, as RPMFusion and Fedora have different processes when it comes to release cycles for updates. Generally, situations like this should resolve itself within a week or so. The conflicts are in place to protect the functionality of whatever it is you installed the RPMFusion variant of a package for. This is a trade-off between systems performing functions users expect (e.g. “I want my computer to display photos I’ve taken with my iPhone”) and the ability to always install the latest version of packages. Generally, RPMFusion tries to err on the side of not breaking user experience.

Having been on the contributing side of both Fedora and RPMFusion I can say that even if you control both the Fedora and RPMFusion side of a split package scenario it is almost impossible to get them to hit download mirrors at the same time. While coordination can reduce the number of days until a scenario like this is resolved it creates a lot of overhead for the contributors on both ends.

There is always a great reluctance to enter into a split package scenario as it does create tension and conflict not only on a technical level (which is what this thread is about) but also among users and contributors. An RPMFusion maintainer of a split package has to develop a thick skin, as many (if not most) of the fallout will land in your inbox to deal with.

So, one thing people have to understand when they’re asking for closer alignment between Fedora and RPMFusion is that there is a vanishingly small group of people that keep RPMFusion going. Every split package scenario creates a lot of overhead and toil trying to stay out of the way of breaking things while providing that extra feature people install the package for in the first place. Often times it’s just not possible. The result is that now you have the anger of users directed at you for doing something you thought was helpful for them. It’s a terribly thankless job. Using some hyperbole: the only time people even notice you exist is when they look up your email address to send you hatemail for breaking their updates (not implying anyone here does that, but I’ve had it happen to me).

That being said, I believe that there could be technical solutions to alleviate some of the impact of this issue. But it would take people to be willing to take a good, hard look at it to then propose and implement it. I’m sure we would have already seen this happen if people with the ability to pull it off had the time and saw enough value in it.


The files are not corrupted. For me it looks like the rpm fusion just uses higher versions who make a problem to install the dependencies if there are some to official repositories (check first four lines i posted as preformated text).

This means it would need some confirmation as if you use libhief-freeworld do not use libhief etc.

I was referring to how to handle such issues, with regards to how and
where to report, against bugzilla at fedora or rpmfusion and such.

The files are not corrupted in your case, but handling such issues is
the same. Also, the post contained already information about how to
exclude in dnf.

However, since it was already reported, it remains with the mentioned


I just tested it. It seems libheif does not require libheif-freeworld at
all, not even as weak dependency. The question is if you have other
tools that need it (hard or weak dependency, “real” dependency of some
of your applications).

If you do not know libheif-freeworld in terms of you have not installed
it intentionally yourself, you can try to dnf remove libheif-freeworld
just to see what is dependent on it, and then make your decision.

If you want to keep libheif-freeworld, you have to wait (and use the
mentioned exclude option as interim solution). In the topic I linked,
you find additionally the possibility to enable testing repos to get the
“solving” update earlier, but I do not think this is worth it (if you
want to keep it, I would just wait).

1 Like

This conflict seems to have gone back and forth for some time.
The real issue is that libheif-freeworld (and its predecessor hibheif-hevc) come from rpmfusion and the remainder of the libheif packages come from fedora. Since these are 2 completely different repos it sometimes happens that they may be out of sync.

If users would understand that this sometimes happens and that it is a timing issue with updates from 2 different source repos then a little patience will most often resolve the conflicts.

At the risk of sounding a bit crass as my grandfather used to say.
Patience little jack…$ Things will work out.


And when running dnf update this morning I got a new libheif-freeworld, resolving the conflict.

Installed Packages
libheif.x86_64                            1.15.2-1.fc38                   @updates               
libheif-freeworld.x86_64                  1.15.2-1.fc38                   @rpmfusion-free-updates
1 Like

This type of situation is mentioned in RPMFusion FAQ. But many users do not know where they install packages from (until there is a problem and they look for someone to blame) and do not read FAQs.

You can not put everyone in the same pot. I’m generally the one who does understand the relationship in between the the packages. This topic is not meant to complain. I more would like to find a smart solution who would avoid errors who can brake a system as happened to me lately.

As long as while installing Fedora Linux I get asked if I want to activate 3.th party repositories or if I need some codecs, I find in the official Documentation links to rpm fusion free, as long we also need to talk about inconveniences who can happen while using this repositories. Also finding solutions makes part of the process and not just say users should read the FAQ!

If I use the official Fedora Repositories there are strict rules and instructions how they have to be used.
If I want to test Software we do have testing and updates-testing. It looks like this also exists in rpm fusion. By default this repo’s are deactivated in official and rpmfusion. Just it looks like that tests in rmpfusion are made also in the “stable” repositories?

This is ok as long as there are just errors who disappear if we are patient, but with errors who make a system unusable as mentioned above (white screen and error), this is not reasonable for new and less experienced users.

Might bee that i overseen some points. So please to discuss this issue we need suggestions and not blame assignments.

Just to add installed updates today and the issue is solved on my end as well.Just had to give it some time. :smiley:

1 Like

Fixed for me as well. Just had to be patient.


It happened again but for a newer version which is in testing now.
Screenshot from 2023-05-09 08-58-36
I just went ahead and installed the rpm from testing:

$ sudo rpm -Uhv libheif-1.16.1-1.fc38.x86_64.rpm libheif-freeworld-1.16.1-1.fc38.x86_64.rpm
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:libheif-1.16.1-1.fc38            ################################# [ 25%]
   2:libheif-freeworld-1.16.1-1.fc38  ################################# [ 50%]
Cleaning up / removing...
   3:libheif-freeworld-1.15.2-1.fc38  ################################# [ 75%]
   4:libheif-1.15.2-1.fc38            ################################# [100%]

I don’t generally recommend doing that. I did take the precaution of using dnf download to acquire copies of the original RPMs so it should be possible to revert back to them in case of issues.

Yeah, it’s happening again.

I find it funny some peoples seem to look for excuses on this, but really : user experience on amd is broken on fedora : that’s all.

Artist ? Videomaker ? You need codecs. But for some reasons, red hat and fedora decide to break a thing that was working before : like codec, or libraires needed for, like, working.

It’s not a “user choice” like it choose to install a programs or stuff like that : it’s a thing needed to work and make you programs work.

Mesa-freeworld, and now this make fedora crash at boot, make errors at update. Don’t say “just wait a little” and never respond to this concern to the users that see a crash error bug when a session launch.

It’s a problem on the fedora ecosystem, and user pay the price for that choice. That’s all. So yeah, the “solution” is hidden in the FAQ of rpm-fusion, great ! And ?

Because, really : packages like this that broke every two weeks or so : it’s a BIG issue.

Don’t see the BIG issue here, holding back an update for a few days. Can’t speak for mesa-freeworld since I didn’t encounter those crashes at boot before, but if that happened to me, I’d just rollback to the state before the update, using snapper.

I absolutely understand your point, but we can’t discuss that topic without acknowledging that there are license issues with those codecs. So, thank god we have Rpmfusion to fix that by providing the needed packages. However, you know better than me that adding third party repositories always comes with a certain risk.

rpmfusion uses koji. Can just anyone use koji? I really do not know the answer to that.

mesa-freeworld is in testing

root@newbox ~]# dnf check-update --enablerepo=rpmfusion-free-updates-testing
Last metadata expiration check: 0:00:25 ago on Wed 10 May 2023 07:33:38 CEST.

libheif.x86_64                       1.16.1-1.fc38              updates                       
libheif-freeworld.x86_64             1.16.1-1.fc38              rpmfusion-free-updates-testing
[root@newbox ~]# 

And why does it brake/miss-match in stable then?

As mentioned above, if it is just a miss-match in dnf there is not a problem. The problem is when it brakes the system and the Oh noo … error comes and people can not work anymore.

  • Problem from the point of view of a rpm fusion contributor might be if it is just in testing, nobody will test it right?

  • As a “simple” user, how can we test the acceleration and codecs ? Are there links to test them to give feedback if we use testing ?

And yes, announcing them as @vekruse did now is a good idea. But probably for a large audience in "News & Announcement " inviting users to test them and also give some ideas how and where.

Yes, it is open source (as is all of the stack that builds the Fedora distribution): Overview - koji - Pagure.io