On Thu, Jul 9, 2015 at 6:44 AM, Matthew Miller mattdm@fedoraproject.org wrote:

On Wed, Jul 08, 2015 at 08:13:58PM -0500, Jason L Tibbitts III wrote:

...

• https://fedoraproject.org/wiki/Packaging:WeakDependencies

Awesome -- thanks, FPC! This is really exciting.

That is exciting! Thanks to everyone involved in this effort. May I suggest a few small tweaks to the wiki page, though?

First, what is a hint? Does that word refer collectively to all weak dependencies? The wiki page doesn't say, so I'm left to guess. The final sentence of the "Hints" section implies that it is something different, but later uses of the word "hint" imply otherwise. If it does refer to all weak dependencies, then I think the page would be much clearer if all uses of the word "hint" were replaced by "weak dependencies". If that is not what the word means, then a definition in the introduction would be very helpful, since there is no definition anywhere on that page.

Second, there are some typos in the "Package Preference" section. Change the following: "a older" -> "an older" "poption" -> "option"

Also, in the final sentence of the "Package Preference" section, change the arrow to a comma.

Finally, the entire "Forward vs Backward Dependencies" section is worded rather awkwardly and contains several grammar and punctuation errors. May I suggest replacing it with this text? (Note that I don't know what "best" means in the first paragraph, so I left that word alone. A definition of "best" would be helpful, also.)

------------------------------------------------------------------------------ Forward dependencies are evaluated for each package that is installed, just like strong dependencies. The best of the packages that fulfill the forward dependencies are also installed. If a transaction will install packages that fulfill reverse dependencies, then the packages containing those dependencies are also installed.

In general, forward dependencies should be used in preference to reverse dependencies. Reverse dependencies are mainly designed for use by third party vendors who supply plug-ins, add-ons, or extensions to distribution packages or other third party packages. Within Fedora, cooperation between package maintainers can eliminate the need for reverse dependencies, as all weak dependencies can be added as forward dependencies in the main package. However, there are cases where it is easier for the main package maintainer if add-ons use reverse dependencies instead. If the main package maintainer agrees to allow the use of reverse dependencies, they may be used in Fedora.

Note, that EPEL or other third party repositories may have (and are encouraged to have) a different policy. ------------------------------------------------------------------------------

Regards,

Jerry James wrote:

First, what is a hint? Does that word refer collectively to all weak dependencies? The wiki page doesn't say, so I'm left to guess.

That seemed perfectly clear to me. Note how the word is introduced: “They come in two strengths: "weak" and "hint" [...]”

The meaning of “weak” is more ambiguous. Sometimes “weak dependencies” is used as a collective term for all weak dependencies, and sometimes it means specifically the stronger kind of weak dependencies.

If a transaction will install packages that fulfill reverse dependencies, then the packages containing those dependencies are also installed.

It took me several attempts to figure out what you meant with that sentence. “Match” as used on the wiki page is a much better word than “fulfill”. The whole idea of a reverse dependency is that the dependency is contained in the package that fulfills the dependency, not in the dependent package, so “fulfill” makes your sentence collapse into a redundant statement that the packages being installed will be installed.

Björn Persson

On Thu, 2015-07-09 at 11:22 -0400, Stephen Gallagher wrote:

Is there any case to allow Supplements: in the Fedora Collection? It seems to me like this could be problematic. (e.g. I write a plugin for a popular engine and package it, then add Supplements: so that it gets pulled in by default whenever that engine is installed. My plugin then causes things to crash.) I think it is reasonable for us to forbid Supplements: except with FPC exemption. It should be up to the owner of the primary package to decide to add Recommends: instead.

The new guidelines say "reverse dependencies may be used with the agreement of the package maintainer of the targeted package" which seems good enough to me.

"Reverse dependencies are mainly designed for 3rd party vendors who can attach their plug-ins/add-ons/extensions to distribution or other 3rd party packages. Within Fedora the control over which packages a package requires should stay with the package maintainer. There are, however, cases when it is easier for the requiring package not needing to care about all add-ons. In this cases reverse dependencies may be used with the agreement of the package maintainer of the targeted package."

On 10. 7. 2015 at 09:45:36, Stephen Gallagher wrote:

On Thu, 2015-07-09 at 10:32 -0500, Michael Catanzaro wrote:

...

On Thu, 2015-07-09 at 11:22 -0400, Stephen Gallagher wrote:

...

Is there any case to allow Supplements: in the Fedora Collection? It seems to me like this could be problematic. (e.g. I write a plugin for a popular engine and package it, then add Supplements: so that it gets pulled in by default whenever that engine is installed. My plugin then causes things to crash.) I think it is reasonable for us to forbid Supplements: except with FPC exemption. It should be up to the owner of the primary package to decide to add Recommends: instead.

The new guidelines say "reverse dependencies may be used with the agreement of the package maintainer of the targeted package" which seems good enough to me.

"Reverse dependencies are mainly designed for 3rd party vendors who can attach their plug-ins/add-ons/extensions to distribution or other 3rd party packages. Within Fedora the control over which packages a package requires should stay with the package maintainer. There are, however, cases when it is easier for the requiring package not needing to care about all add-ons. In this cases reverse dependencies may be used with the agreement of the package maintainer of the targeted package."

I guess I'd have preferred stronger wording. Something to the effect of "reverse dependencies may not be used except with the permission of the package maintainer of the targeted package."

While I see your point and I'm not completely against the wording you used, I have to say that it would beat the main idea behind reverse weak deps: To have a way of creating dependencies in situations when the maintainer is non- responsive or for example against having the dependency in his spec file for whatever (valid or invalid) reason. Note that this is also the reason why there is no reverse Requires.

I think at least in the case of Enhances, there is no reason why to implement the restriction, as creating this dependency is not invasive to the enhanced packages IMHO.

Thanks Jan