Do you have a specific example that might help to clarify you question?

I suspect an example would be a piece of software with a plugin architecture that has one or more plugins that upstream normally ships included but that would be unacceptable for Fedora. So in theory, the core package could be built in Fedora or COPR and the plugin built in RPMFusion.

The primary difference there from Fedora proper would be that they are asking if it's acceptable for COPR to have an explicit Requires: rpmfusion-plugin where in Fedora of course it would be impermissible to depend on something outside of the core repositories.

(As a corollary, I'd also like to ask what our stance would be on Recommends: or Suggests: in Fedora proper.)

CCing spot for a legal interpretation of my supplementary question.

Replying to [comment:2 sgallagh]:

(As a corollary, I'd also like to ask what our stance would be on Recommends: or Suggests: in Fedora proper.)

To clarify, I'm basically asking whether that (now that we have weak dependencies), if it would be legally acceptable for a spec file for something like gstreamer1 to add Recommends: gstreamer1-plugins-ugly. (Or even simply Suggests: gstreamer1-plugins-ugly)

My rationale: we are not ''providing'' these packages directly. They would only be available to the user if the rpmfusion package had already been installed manually, which presumably means that the user had determined their own legal status for doing so.

So we are talking about RPM dependencies then? The question, as presented, wasn't clear to me but I suppose that is the most logical conclusion.

Personally, I do not think COPR packages should carry Requires: pointing to third party repository packages. It strongly ties the COPR package to something Fedora does not provide, making it unacceptable for us to ship.

I will have to think about Recommends and Suggests. Mostly after I figure out the semantic difference between the two.

Replying to [comment:5 jwboyer]:

I will have to think about Recommends and Suggests. Mostly after I figure out the semantic difference between the two.

The semantic difference is this: If a package Recommends: another package, DNF will (by default) install that other package so long as it is functionally capable of doing so (the package exists in an enabled repository and its own Requires: dependencies can be met. There is a flag to DNF that can disable this behavior so that only strict requirements are added. Removing a Recommended package later will not remove the first package.

If a package Suggests: another package, it is eligible for the package manager to display it to the user as something they may also want to install, but it will not be installed automatically. DNF provides a flag that can treat Suggests as Recommends for users who want a larger set of available features. Removing a Suggested package later will not remove the first package.

In reality, Suggests: is rarely used for any purpose, but Recommends: can be a very valuable tool.

Replying to [comment:6 sgallagh]:

In reality, Suggests: is rarely used for any purpose, but Recommends: can be a very valuable tool.

Maybe this means we've drawn the definitions for these too loosely. What if we made Recommends a stronger thing ("package may not actually function as expected without workarounds if you remove this") and use Suggests for "package will work without this, but may be missing functionality", as we are basically using Recommends today.

Here's what prompted it: https://copr.fedoraproject.org/coprs/gferon/openjfx/

It builds against ffmpeg in rpmfusion (BuildRequires: ffmpeg-devel, rpmfusion repos listed in the copr buildroots). This results in a dep on libavcodec.so.56, etc (although the package is packaged poorly so the requirement is removed).

Replying to [comment:8 mattdm]:

Replying to [comment:6 sgallagh]:

In reality, Suggests: is rarely used for any purpose, but Recommends: can be a very valuable tool.

Maybe this means we've drawn the definitions for these too loosely. What if we made Recommends a stronger thing ("package may not actually function as expected without workarounds if you remove this") and use Suggests for "package will work without this, but may be missing functionality", as we are basically using Recommends today.

I think the differentiation as it exists today is the correct one. For best experience, we recommend that these are installed, so we do so by default. For lesser-used features, we suggest you may also want to install these packages, but we're not going to put them on your system without your input.

Perhaps we should work on better UI for this, but I think the approach is sound. Anything that wouldn't function as expected without workarounds should (in my opinion) be a strict requirement. For truly special cases, this can be separated out as foo-core if there are rare cases where non-fully-functional installation is useful.

Replying to [comment:9 orion]:

Here's what prompted it: https://copr.fedoraproject.org/coprs/gferon/openjfx/

It builds against ffmpeg in rpmfusion (BuildRequires: ffmpeg-devel, rpmfusion repos listed in the copr buildroots). This results in a dep on libavcodec.so.56, etc (although the package is packaged poorly so the requirement is removed).

That, very concretely, is not allowed. It is both BuildRequire'ing and dynamically linking, which are both explained as forbidden in the original email thread.

That package needs to be removed.

Ah, sorry I missed that. I've reported it. I guess everyone else will still get to debate the other issue though :)

Changing the ticket title to reflect the actual question here.

Again, the runtime deps may or may not be implemented by Recommends or Suggests per the conversations above.

AGREED: package build in copr must be functional with requirements complying w/ Fedora licensing policies. Dependencies using third-party repositories are ok if they are non-essential at runtime (e.g Recommends/Suggest) (+8, -0, 0) (jwboyer, 17:38:30)