I'm not really sure what you expect us to discuss. The RPM/Yum/DNF folks upstream are already working on their next major change, which is expected to include some pieces of libsolv. "Soft" dependencies are on their TODO list, I believe.

Libsatsolv and soft deps are orthogonal things.

I'm just messanger as Florian Festi in https://bugzilla.redhat.com/show_bug.cgi?id=1006954#c5 (last bullet of his comment) want from FesCo clear statement that Soft Deps are welcome in Fedora.

I do not understand it either, but since Florian is on rpm development team I do not debate on this. And I do not expect big debate on this from FesCo.

Simple voting on this, and statement "Soft depenencies {are|are not} welcome in Fedora" should be enough.

Okay, read that ticket. I think there's insufficient data for FESCo to make a statement. The reason is that simply saying "soft requirements" leaves a lot open to interpretation when it is implemented. As Florian points out, a lot of interpretation is up to the dep solver so that might be the place to take an initial look.

Debian's implementation of soft requirements are not totally applicable to us as we consider it a feature that installs are unattended. So there has to be some thought as to what soft requirements look like then. Do you always install some, and never install others? In that case, what makes them different from hard requirements and not listing a requirement at all? Perhaps whether they're installed on a box is settable by the sysadmin. In that case, what are the reasons to need more than one type of soft requirement? In the case where a sysadmin has the default to install soft requirements but for a specific package, they have uninstalled the soft requirement will the depsolver be intelligent enough to handle that or will it continually install the soft requirement when the package is updated?

Note -- this is somewhat more positive than the tilde-in-version case that Florian mentions, but I still don't think FESCo should be making a statement about whether we'd use soft requirements without more of a plan.

So, I can think of several examples of soft dependencies off the top of my head (some taken from Debian and thus using their terminology).

• Recommends: Most deployments that use this package will also want this package. However, we may want to allow you to be able to remove it if you don't need it (such as on embedded systems).
• Suggests: Most deployments won't need this, but it adds some useful functionality when it's installed. This is one we can probably do without, but I'm listing it for completeness.
• Requires-if: Install this package if some other condition is met on the system. For example, if both the 32-bit and 64-bit versions of glibc are installed, make sure to install both sssd-client.x86_64 and sssd-client.i686 (this one has bitten a lot of people over the years)
• Supplements: I have a new package that adds significantly useful functionality to some other package. I want it to be treated as if the other package claimed "Suggests: mypackage" but I don't have control of that other package. This is also one we probably don't want, but I've heard people ask for it.
• Disapproves: Soft version of "Conflicts:". In other words, "we recommend that these two packages do not coexist, but we won't stop you". Probably treated the same as "Conflicts:" unless an override option is passed. Might be useful for e.g. mod_ssl vs. mod_nss.

I know there are more to consider out there, but these should be good for seeding the discussion.

So there has
to be some thought as to what soft requirements look like then.

Yes. But that is different topic. I do not want to discuss how soft dependencies in Fedora should looks like, what should be implemntation... I want from FesCo just simple answer: Do we want soft deps at all.
We had for ages only hard deps. So lets start with this simple question. If the answer will be "Yes", we (or you) can then start debate how we want to implement it. But that is different task, should be different ticket.

Do you always install some, and never install others?

Leave it up to admin, and up to tools above rpm.

In that case, what makes
them different from hard requirements and not listing a requirement at
all?

Because hard requirements will force you to install packages which are not strictly required (e.g. perl modules for MidnightCommander). Or does not give hint to admin that there are packages which can enhance the packages he is going to install (e.g ModemManager for NetworkManager).

Perhaps whether they're installed on a box is settable by the
sysadmin.

Nope, it is settable by interactive tools above rpm (e.g Apper, DNF, YUM...). RPM itself will still enforce just that hard requirements as is now. And rpm itself - in form as suggested in bug 1006954 - can completly ignore those soft deps (just recognize them as valid tokens) and leave the handling for interactive tools above rpm.

In that case, what are the reasons to need more than one type
of soft requirement?

a) because it brings better user experience

b) because everybody else is using it. And we does not fulfill our motto “Freedom, Friends, Features, First”

In the case where a sysadmin has the default to
install soft requirements but for a specific package, they have
uninstalled the soft requirement will the depsolver be intelligent enough
to handle that or will it continually install the soft requirement when
the package is updated?

That's up to that interactive application above rpm. That is not task for rpm. And definitely not topic for this ticket.

• AGREED: FESCo would be OK with some implementations of soft dependencies. To get a more clear ACK or NAK, come up with an implementation design (+7, 0, -1) (sgallagh, 19:08:57)