[Guidelines change] Changes to the packaging guidelines
jzeleny at redhat.com
Fri Jul 10 14:03:25 UTC 2015
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
More information about the devel