The rpm 4.12.0 change brings in 'weak dependency' support.
That is: Recommends, Suggests, Supplements and Enhances.
We currently have no guidelines around their use.
Rpm accepts them, but doesn't use them at all. Yum only adds them to metadata in createrepo, but thats it. Dnf does actually use the metadata where it exists.
(see: https://bugzilla.redhat.com/show_bug.cgi?id=1086274#c7 )
This results in very different deps when a user uses dnf vs yum.
I'm not sure if this needs/should go by FPC, but this seems more like a policy decision than a guideline.
Possible Proposals:
Announce to devel-announce and add to the wiki that maintainers are not to use these weak dependency tags until such a time as guidelines are finalized and FESCo lifts the ban.
and/or
Add some check in redhat-rpm-macros or koji to reject builds with these tags until we give the all clear.
FWIW, I see the following packages using these in rawhide:
./dreamchess/dreamchess.spec:Suggests: %{name}-engine = %{version}-%{release} ./dreamchess/dreamchess.spec:Suggests: gnuchess ./bcfg2/bcfg2.spec:Recommends: cron ./ceph/ceph.spec:Recommends: logrotate
== Looking forward ==
I don’t think we generally require having a packaging guideline for every RPM feature before that feature can be used. And if the consensus is that dnf will be used in the future, we seem to be going basically in the right direction.
Specifically, what do you envision the FPC guidelines to look like?
== Implementation ==
Repeating myself from earlier today:
I will no longer tolerate/support any packaging guideline changes which, without expanding Fedora to an entirely new ecosystem/use case, add manual packaging or package review work. We are software developers, and the way we solve problems in our area and in this century is by writing software.
I would much prefer a redhat-rpm-macros/koji version. An announcement is fine but this ''shouldn‘t'' end up with yet another written down / manually verified guideline.
== Philosophy ==
I might even support forbidding this without the “for now” part. In other parts of the universe (Cloud images, Docker, Atomic, the various proposed new application models) we are trying to simplify software delivery, and if possible to completely hide RPM dependencies or even RPMs as such, so it seems kind of weird to be expanding complexity of the dependency model underneath at the very same time.
But I know I am in a small minority, there are both RPM developers that wanted to implement this, and various users that want to use this. So I must be missing something.
Well, when should you use weak dependencies vs strong ones? I'm not even sure without looking further how dnf treats them. Does it ask? Does it just install Suggests? There are a number of ways weak deps could be handled in the package manager layer.
The problem with a macro checking these and failing builds is that then people couldn't use koji to scratch build stuff to test with, etc. I suppose they could use copr though as long as the macro wasn't active there somehow.
I'm going to drop this proposal.
Since it seems that after investigation dnf doesn't really do anything much (uses them for tie breaking in libsolve if there's two providers) with them either.
We can wait until dnf does more with them and hopefully have guidelines and such by then.
Login to comment on this ticket.