2016-09-03 13:50 GMT+02:00 Dominik 'Rathann' Mierzejewski
<domi...@greysector.net>:
> Dear RPMFusion contributors!
>
> In light of https://fedorahosted.org/council/ticket/61 and
> https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal
> should we start adding Supplements: or Enhances: weak dependencies
> to, say, ffmpeg and other packages?
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).
>From a technical perspective, there might be missing components that
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)
