Ralf Corsepius wrote: Why? This use case is exactly what the reverse versions are for. The Fedora repository should not know about RPM Fusion, RPM Fusion should know about Fedora. So why should Fedora carry the weak dependencies on RPM Fusion packages? Kevin Kofler

Ralf Corsepius wrote: And that is exactly why RPM Fusion needs to carry reverse dependencies instead. There are no reverse hard dependencies. (RPM deliberately decided to not support them, because adding a repository must not introduce broken dependencies on a system.) So the reverse dependencies must be weak. Kevin Kofler

2016-09-03 13:50 GMT+02:00 Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net&gt;: I don't understand the Workstation 3rd party proposal yet. I think it's not even relevant to us and even less relevant to the Suggest/Enhance discussion raised here. So I'm only focusing on the council ticket 61. This ticket currently states few things: 1/ Fedora packages aren't allowed to use Suggest/Enhance (even less Requires) for packages outside of Fedora Collection proper. 2/ If "Recommends/Suggest" was appropriate of a particular Fedora package to point to a 3rd party package , then the alternative and workaround is to use "Supplements/Enhance" from the 3rd part package to the fedora one, which is the reverse "Partners". So first when talking this isn't a new topic. We already have experienced the same kind of behavior when yum has gained the capability to merge all repos groups (1) together and install new packages from the merged groups. Before that time, our groups was mostly relevant for display in yumex and at install time (anaconda) for users having enabled the repos with a kickstart file or during the anaconda installation. After that, all users was affected by our repos design and some users complained about "packages installed in their back" on the next yum update. That was mostly because we had gnome-mplayer installed by default in the Desktop group, which isn't desired by some users. Later the new yum feature was reverted (IIRC) before we had redesigned the groups layout with a better minimal default for the next Fedora release. With theses weak dependency, we are moving a property from the repo to a particular package. Which means we need to rebuild the package each time theses property have changed. Just to be accurate, we are not taking about allowing weak dependencies in RPM Fusion, those should be allowed as per the Fedora packaging guideline that unless stated otherwise and apply to us. (Just before someone raise the point, we do not allow Fedora to make direct decision to some concern that apply to us, as we are nevertheless a separate project). will make theses new RPM features not to be seen in the repodata, but that's fixable. You might dislike weak dependencies, but then that remains a packager own taste. Now let see how reverse weak dependency can be implemented in RPMFusion with few examples: - rpmfusion-{,non}free-appstream-data: Would use "Supplement/Enhance". In this case, this is probably a good usage of reverse dependency because only if the end-user has appstream-data, the rpmfusion counterpart will install. From the rpmfusion's appstream-data package, there is only one single relation to add to appstream-data. If we were to implement the reverse, that wouldn't be maintainable, because each time a new repository rise up (or drops), the appsteam-data maintainer would need to stay aware of this and issue a new update. This would be a totally un-scalable workload. - firefox and multimedia plugins. npapi-vlc or xine-plugin might had grow a Supplements: firefox, but then are we sure that we had vlc or xine in the first step ? if using RPM weak dependencies over yum groups, with yum it was possible to involve groups belonging and conditional, so if vlc was part of the extended KDE group and firefox was selected, then npapi-vlc would be installed. This is still an issue for end-users not wanting npapi-vlc but at least it was possible to bring a coherency from the SIG maintainer. With the current Supplement/Enhance situation, you can only have one single conditional from the base package, so it would be better not to add the Supplement in npapi-vlc and xine-plugin at all. - libva-intel-driver, would supplement libva. But then are we really sure to be on the related hw ? Some users have reported issue on old hw, so having this package installed might bring bugs. Better to do nothing here. (not to mention that some arches don't even have any vaapi backends). - ffmpeg (which is the example rised by the council ticket by the sway review request). sway will only use the ffmpeg binaries (not libs). One concern raised by councils members is that using Recommands: ffmpeg would enforce a "blessing" of a certain repo with a good packaging. So they are adding an additional spurious rule along with the ffmpeg restriction which this time isn't really backed with legal restriction. I would have preferred to have them to allow a Recommands ffmpeg-bin-weak (or any other arbitrary names) in order to have a packaging agnostic version of the appropriate weak dependency instead of putting the effort and decision to use weak dependency to ffmpeg for the ffmpeg maintainers. (which might be a big hundred). The other issue if that if the sway(or others) packagings changes, then there will be a need to adapt the ffmpeg tag with the appropriate sub-package. This isn't scalable and I would name this kind of un-natural dependencies "perverted weak dependency" with the explicit aim to forbid that in our repo. If the Fedora council will amend their policy to find a better workaround than using reversed weak dependency, my proposition is to find alternate naming for the Recommends so that it doesn't depend on a particular repo (despite I don't consider this argument as relevant). Or to rely on "upstream name" of the package (assuming the package that contains -binaries to be the main package or using -bin virtual Recommands). The other way is to verify that package using RPM Fusion binaries work as expected when using PackageKit-command-not-found and rely on the current repos metadata to install the appropriate binary instead of relying to an arbitrary package information. Any others thought ? advice ? (1) http://cvs.rpmfusion.org/viewvc/comps/comps-f20.xml.in?revision=1.2&r... -- - Nicolas (kwizart)