On Thu, Jul 9, 2015 at 6:44 AM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote: 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 http://www.jamezone.org/

Jerry James wrote: 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. 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: 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: 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