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.
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.
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).
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.
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.
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.
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.
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.
That seems a user workflow requirement.
Codecs are required for multimedia tasks, and fedora includes some but excludes others.
It is a user choice to perform tasks requiring the codecs that are excluded and it is user choice to install those codecs from a 3rd party repo. If one cannot accept that sometimes it is necessary to locate and install software required then that is also user choice.
In fact, when using windows it is required to purchase and install software for more than the most trivial of tasks – often with a subscription fee today instead of a one time license purchase as it has been in the past. Again, user choice to be able to perform the desired tasks.
