+1

This definitely needs an issue open for discussion as I think it's not an insignificant change.

OK, let's discuss ;)

I guess it is understood that this change will not have it's full effect in a short time.
Aim, in my perception, is to minimize dependencies so that software can be chosen more freely.

Certain software ends up on systems where it cannot be used, e.g. bolt on a thunderbolt-less system, iio-sensors-proxy on system without these sensors, wifi firmware on systems without wifi.
Also certain software might not be desirable but cannot really be removed (e.g. gnome-online-accounts).
There might be more situations where a choice cannot be satisfied by the packaging system.

This means that packages SHOULD NOT have a Requires, Recommends, or Supplements on any other package, unless the dependency is required for technical reasons or truly makes sense to have.

I mean, this should really be the case anyway. I don't see why packages should have dependencies when it's not required for technical reasons or truly makes sense.

However the explicit rule about desktop files was actually there for a reason. Users get confused when they install coolapp_written_in_java (or libreoffice) and suddenly they see OpenJDK 1.8.0 Policy Tool 1.8.0.191.b12-11.fc29.x86_64 in their menus.

I mean, this should really be the case anyway

Well, yes, that's what seasoned packagers expect and treat as obvious. But the rule wasn't actually stated anywhere. A new packager or user might reasonably wonder whether a dependency on a related-and-useful package should be added or not. In Fedora we say "no", but a different distro which values ease-of-use over a little bit of disk space might answer "yes". How to decide this doesn't have a strict technological basis, and we need to draw the rule somewhere. I think that explicitly stating the rule is useful.

However the explicit rule about desktop files was actually there for a reason. Users get confused when they install coolapp_written_in_java (or libreoffice) and suddenly they see OpenJDK 1.8.0 Policy Tool 1.8.0.191.b12-11.fc29.x86_64 in their menus.

Ack. The proposed update is a superset of the old rule, so the graphical app case is still handled. I can add back the mention of the graphical app case explicitly if you think it's important.

I think it's explicitly important. But let's wait for the opinion of others before you change things, so you don't need to change back and forth.

I would like to have guideline which says something like:
* If it's mandatory dependency (aka app won't work without this dependency), the you MUST use Requires
* If it's optional dependency (aka app will work without this dependency), then you MUST use Recommends or Suggests
** In case this functionality should be available by default for users, you MUST use Recommends
** Otherwise, you MUST use Suggests
* Desktop applications should not depend on other desktop applications unless strictly required.

Shouldn't there be a well formulated text about what effort the developer must invest to make their software as independent as we like it to be?
Our could we cover this case by stating that at any time the user should be able to remove the software without hampering certain core functionality?

Updated to address @churchyard's and @ignatenkobrain's reviews.