#61 Fedora Packaging Guidelines: Weak Dependencies on packages from third-party repos
Closed: Fixed None Opened 7 years ago by maxamillion.

Currently there are not guidelines on whether or not a Weak Dependency can reside in a third-party repository or must reside within the Fedora repositories as with hard Requirements.

I am doing a package review and one of the software's utilities requires ffmpeg but since we don't offer that, the packager requesting review moved it into a "Suggests:" directive and I'm unsure of how to properly handle that at this time.

Please advise.

https://bugzilla.redhat.com/show_bug.cgi?id=1308561


Historically, Fedora Requires: have only been allowed to reference packages within Fedora. This made sense, since Fedora needs to be internally consistent and we wouldn't be able to achieve repoclosure otherwise.

However, now that we have Recommends: and Suggests: dependencies available, it makes sense to revisit this. For example, in this particular BZ, we have a package that is ''functional'' without ffmpeg, but gains some considerable additional functionality if ffmpeg is present. If ffmpeg was in Fedora proper, I'd say that would be a clear case for a Recommends: dependency (so it would be installed by default but not critical for all operation).

However, Recommends: has a secondary feature which is that it will be ignored if the recommended package is not present in any configured repository. So if the necessary third-party repositories are not installed or enabled, the package would just install without those extra features. This could actually be a very desirable situation.

I see the following possible decisions that the Council could make:
1. Packages in the Fedora Collection may only reference other Fedora Collection packages in any dependency, strong or weak.
1. Packages in the Fedora Collection may use Recommends: and Suggests: that reference packages in third-party repositories, but may not Requires: them.
1. Packages in the Fedora Collection may use Recommends: and Suggests: that reference packages that are distributed under an acceptable open-source license in third-party repositories, but may not Requires: them.

Given the nature of the weak dependencies, I'd argue that it's reasonable to assume that if a user has enabled a third-party repository, they have made a conscious decision assuming the risks (technical, security and legal) to use software from that repository, so allowing the use of Recommends: makes sense to me, but I also don't know whether there is any additional legal consideration to be made.

Note: this decision is not limited to the current situation. A decision here to allow weak deps could also theoretically lead to the graphics stack adding Recommends: for proprietary drivers (if we allowed closed-source), so that needs to be considered carefully.

For the sake of argument, are we going to ignore that different third party repositories may package a piece of software differently? We cannot do anything about it, but making a blind assumption that Recommends: ffmpeg would lead to everything working seems a bit careless.

If we aren't ignoring it, then it means we need to vet which third party repositories package it correctly and make sure we have coordinated efforts with them. Which is a very large rathole.

Replying to [comment:3 jwboyer]:

For the sake of argument, are we going to ignore that different third party repositories may package a piece of software differently? We cannot do anything about it, but making a blind assumption that Recommends: ffmpeg would lead to everything working seems a bit careless.

If we aren't ignoring it, then it means we need to vet which third party repositories package it correctly and make sure we have coordinated efforts with them. Which is a very large rathole.

That's a good point, would it be possible to vet a small handful of third party repositories and say that packagers may Recommend: or Suggests: from those repositories? (I worry that's going to get off into some legal rabbit hole in itself though, but I thought maybe we could try and rate-limit the potential for problems)

I think if we did vet 3rd party repos and use the name of packages from one, but not another it would be a defacto 'blessing' of that repo by Fedora, which I think would be wrong.

We can't really know what repo the packager had in mind, and they cannot point to it, so I think we should just forbid using deps outside the Fedora collection to avoid blessing any one repo or confusing our users as to which one(s) they should use.

Well, this is something that can be worked out through. For instance, FPC could standardize "external" provides to use a namespace so that third-party repositories can fix their packages to work against ours.
Third-party repositories can already break our packages, so this is not a new issue, all we can do is provide a standardized interface for them

The real blockers are weighting the legal risk, and how it affects our mission.

Was this discussed at this week's meeting? Any update?

We discussed it very briefly: https://meetbot.fedoraproject.org/teams/council/council.2016-07-18-18.00.log.html#l-74
and I put it in my court to get input into the potential legal risk as the next step.

Hi,

I don't see possible legal problems (but probably I'm a little bit short-sighted on this topic).

As for the mattdm point in the meeting about the possibility that a third party repo provides a package with the same name but with completely different features, this is always a problem (even with core packages) since any repository can 'override' other repositories packages (using a higher version number).

I think the problem is more about the fact mentioned by Kevin affirming that if we 'vet' one repo but not others, this is like saying that Fedora endorse those 3rd party repos.

I'm conflicted about this. I agree to kevin's concerns in comment:5, namely that we don't want to bless any 3rd party repos. We can only bless what we control.

If we allow dependencies on packages from 3rd party repos, then
we should only allow it for "Suggests". "Recommends" should be limited to our own repos.
we need to think think carefully what dependencies we allow. Only package names or also on files?

My inclination is to say that we should not use these, and instead suggest that third party repos which offer packages which add to those in Fedora proper use the "backwards" weak deps, Supplements or Enhances (which are the partners to Recommends and Suggests, respectively). This accomplishes the same thing from a user perspective without Fedora needing to mediate or recommend specific repositories.

I am concerned that adding suggets or reconmends on something like ffmpeg could potentially open up Legal liabilities for unlicensed patented codec use. I think that in the third party repos they should use Enhances and Supplements. There is a reason why things are not in fedora, if we link Fedora too closely to any of them it could be seen the same as fedora shipping them.

Replying to [comment:11 mattdm]:

My inclination is to say that we should not use these, and instead suggest that third party repos which offer packages which add to those in Fedora proper use the "backwards" weak deps, Supplements or Enhances (which are the partners to Recommends and Suggests, respectively). This accomplishes the same thing from a user perspective without Fedora needing to mediate or recommend specific repositories.

I agree with this approach.

+1 to mattdm's proposal (concur with jwb)

Approved:

Third party repos which offer packages which add to those in Fedora proper should use the "backwards" weak deps, Supplements or Enhances (which are the partners to Recommends and Suggests, respectively). This accomplishes the same thing from a user perspective without Fedora needing to mediate or recommend specific repositories.

Login to comment on this ticket.

Metadata