I don't think FESCo can do anything here. Also I don't think that we need such granularity... For instance, why would you not like to have iio-sensors-proxy on your system? What if you get some device which requires it. Or you replace wifi card and you don't have firmware for it anymore.

So what I wanted to say, freedom of choice should be only to some extent, but not too much.

We do not have these iio sensors on the system.
So why carry software for stuff that is not present?
We do not have wifi.
So why carry software for stuff that is not present?
We do not need those sensors nor wifi, still this software ends up on my system.
If Fesco cannot do anything here then who can?
There is no policy, no strategy, no plan?

If Fesco cannot do anything here then who can?

Somebody needs to propose a Change with some specific plan how to implement what you are asking.

TBH, I have no idea how to make this work, for firmwares you would need to change packages with firmwares and make DNF aware how to pull them in. But iio-sensors-proxy is not working that way, gnome-settings-daemon (or whatsoever else) is linked with it. So you actually need to recompile RPM and remove that support.

I think only Gentoo has such options available and only because it is source-based distribution.

g-s-d as a 'technical' dependency is a design issue.
I explained what all these dependencies are causing.
I know there's hard and soft dependencies in dnf's world.
Technical ones like iio-sensors-proxy vs g-s-d is a design issue.
It means that no one ever considered that one can have systems where all of these non useful packages are not welcome.
First there needs to be a strategy, policy, then a plan, then perhaps a design.
Then we know we tried to do some things certain ways but perhaps in certain cases we cannot or it is not very reasonable to do so.
At present it appears that nothing like I mentioned is in existence.
This means that everyone is doing their thing and no one is paying attention to certain very basic details.
See iio-sensors-proxy, see gnome-online-accounts, NetworkManager, the screen sharing network thing in 'Settings' etc, etc.
Fedora simply 'happens' without all these basic details taken care of.

If Fesco cannot do anything here then who can?

Somebody needs to propose a Change with some specific plan how to implement what you are asking.

A change per package? This needs to be standard policy. What else does Fesco think they are delivering to the community? 'a Distro' of course, but what are the key features? No /not/ the latest GUI implementation and all that, but the very basic functionality that /also/ can make the user happy. What things policy-like /are/ written down?
And even if we do a change: what to do about the support person for e.g. gnome-online-accounts? This package has great designs but is missing the very basic off switch or even the possibility to not install the thing. The person does not want to even recognise these issue.

I generally would agree that minimizing deps is a good thing, but it's something to consider on a case-by-case basis. There is nothing for FESCo to do here. My vote is just to close this issue.

If Fesco has nothing to do here, who will tap each developer on the shoulder and tell them what are the good ideas for fedora and thus for 'his' packages?
If Fesco has nothing to do here, will the burden be pushed towards the end users?

The 'mission' as I read it at https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee states:
FESCo handles the process of accepting new features, the acceptance of new packaging sponsors, Special Interest Groups (SIGs) and SIG Oversight, the packaging process, handling and enforcement of maintainer issues and other technical matters related to the distribution and its construction.

'Modularity' could be handled as a new feature.
'Modularity' could be handled as a check in the packaging process (what dependencies are there? are they needed? are they of the kind that could be removed with some programming?).
'Modularity' could be handled as part of technical matters related to the distribution and its construction.

So I guess it appears to be time to rewrite that mission...

So I guess it appears to be time to rewrite that mission...

Not really. It says FESCo handles the process of accepting new features, not that it implements new features as requested by users.

So I hand to you an acceptable new feature and then Fesco does?

Fesco does: accept the feature or not. There still needs to be heavy lifting by the ones involved in the implementation. I suggest you read this:

https://fedoraproject.org/wiki/Changes/Policy

The implementation details are very high level. The decision can be simple.
The heavy lifting is by the developers.

When I read I all this there appears to be no policy on this kind of level (modularity, freedom of choice, etc, etc). Please confirm.
If so, wouldn't you think that this is sorely missing?

The packaging guidelines [1] say:

Applications SHOULD be installable independently whenever this is technically feasible. Packages [...] SHOULD NOT have a Requires, Recommends, or Supplements on any other package [...], directly or indirectly, unless the dependency is required for technical reasons or truly makes sense to have.

The quote is actually only about desktop applications, unfortunately. We don't have a written general rule that would apply to any package. But even an explicit rule, it is generally understood that packages should be kept independent unless there's a good reason. I'll file a PR against the Packaging Guidelines to make the text apply to all packages.

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_application_independence

https://pagure.io/packaging-committee/pull-request/844

As an overall project, Fedora is trying to enable people to create solutions that work for different use cases - the Fedora Editions are a primary example of this. Because components are shared between different types of solutions, there is often a use case for flexibility and dependency minimization. What you need for a minimal container image is quite different for what you need for a full desktop, and if systemd hard-required everything needed for a full desktop, that would be a huge problem.

However, we should not pretend that making dependencies optional has zero cost. If we made iio-sensor-proxy an optional dependency of gnome-settings-daemon:

• There would be multiple code paths in the code to handle the proxy and no-proxy case - with the no-proxy case almost never being tested.
• Upgrading from an old version of Fedora could leave a user with a system that was very subtly broken - because nothing was pulling in the package that was meant to be part of the system. (†)
• We would need extra code, a designed user interface and translated strings - to detect the situation say "If you want light level sensing (‡) to work, please install the iio-sensor-proxy package"

In general, making dependencies optional because on one particular piece of hardware they are not needed does not seem like a burden we should impose on packagers, especially when doing a quality job of making a dependency optional requires significant upstream work.

(†) As more users deploy Fedora via ostree based systems, there is less need to use dependencies to enforce a working operating system across upgrades, but most users are still consuming Fedora via loose rpms.
(‡) I think this is one of the use cases of the package, but not stopping to look it up now.

Though I agree that we should generally be careful to go light on the use of Requires in our packages, I don't think Fedora's goal is to make an extremely customizable distribution (in comparison to other available distributions, and in the sense that you can get an extremely thin package set). As Igor noted, there are distros (Gentoo and derivatives) that have this as an explicit goal, and it is easier for them to do that since they build the source on the users' machines.

If there is a specific actionable suggestion for a specific package, I think the best course of action would be to file a bug against that package. I don't think there is much for FESCo to do here.

I think Requires should only be used if the dependency is truly required for the package to work. We should be using Recommends or Suggests wherever possible.

I'm going to close this ticket since it doesn't have a specific proposal. If anyone wants to make a well specified proposal, feel free to reopen.

The quote is actually only about desktop applications, unfortunately. We don't have a written general rule that would apply to any package. But even an explicit rule, it is generally understood that packages should be kept independent unless there's a good reason. I'll file a PR against the Packaging Guidelines to make the text apply to all packages.

Thanks!(!)
Who will enforce these rules, even for existing package with existing situations that might not sit well with this change?

Another example:
Someone has decided I need sandboxed desktop applications.
AFAIK I do not have sandboxed desktop applications nor do I have wishes to use sandboxed desktop applications.
So we do some research:

rpm -e flatpak

error: Failed dependencies:
flatpak >= 1.2.0 is needed by (installed) xdg-desktop-portal-1.2.0-1.fc29.x86_64
/usr/libexec/flatpak-validate-icon is needed by (installed) xdg-desktop-portal-1.2.0-1.fc29.x86_64

rpm -e flatpak xdg-desktop-portal-1.2.0-1.fc29.x86_64

error: Failed dependencies:
xdg-desktop-portal >= 1.1.1 is needed by (installed) xdg-desktop-portal-gtk-1.2.0-1.fc29.x86_64

rpm -e flatpak xdg-desktop-portal-1.2.0-1.fc29.x86_64 xdg-desktop-portal-gtk-1.2.0-1.fc29.x86_64

error: Failed dependencies:
xdg-desktop-portal-gtk is needed by (installed) gnome-shell-3.30.2-1.fc29.x86_64

So there's no dependency to any flatpak-type of application but to part(s) of the GUI that I use.
That is a fake dependency:
Make flatpak dependent on flatpak-type things and /not/ on the things I generally use, that are not flatpak.

Modularity is kinda gone in this one. Can we please bring it back?

What is insufficient about the modularity issue?
Insufficient explanation was given so I dould not react before.
Not all hardware is to be presumed present on all systems. Not all services are needed on all systems.
I.e.:
One does not always need things like: iio-sensor-proxy, ModemManager, various firmwares, gnome-online-accounts, etc, etc, etc.
Freedom of choice, freedom NOT to install, use a package (rpm) should be the leading consideration.

The proposal is thus simple:
Install rules for package managers/creators that make sure that most of the freedoms described are implemented. Enforce those rules.

@udovdh This is not a proposal, it's a complaint. The purpose of a distribution is not to give you every possible choice. If you want that level of control, build your own distribution. The purpose of a distribution is to assemble the various available projects into a cohesive whole. If you disagree with some of the chosen defaults, remove them. If they can't be removed, there's probably a good reason for that.

Please stop reopening this ticket.

The proposal is to improve, as I see modularity as an improvement.
Seeing it solely as a complaint is a statement.

A chohesive whole? Could be.
But I do not need all that stuff. And the way things are built (not always with good reason) limit my ways of removing things.
Probably is not good enough for me.
See the gnome-online-accounts issue. The author refuses to admit any issue.
See all the asumed hardware, services etc that the user could have.
It is crud that needs to go.
I can see that this cannot change soon into a black/white situation but a little more modularity comes a long way.

Reasons for modularity:
- hardening
- less cpu/ram/disk consumption
- performance
- customization
- ...
A little more freedom in modularity towards the end user comes a long way.