No subject

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&root=free&view=markup


-- 
-

Nicolas (kwizart)