English Burmese
Active support from our maintainers, the FPC, and other community members is definitely needed. This is obviously not something we can "request", but it's still a necessary input.
A - If systemd is only needed to start services, a package should only "Recommend" systemd.  This will allow containers to install the package without systemd.
Also, consider looking at container-native use cases, such as:
An active focus on minimization means that our maintainers produce size-optimised content with the same or lower amount of effort. Tooling, services, and data help them to make the right decision about dependencies easily, and to keep things smaller over time.
A specific example is Systemd — while being very useful (everybody loves Systemd) and is always present on physical systems, it is rarely needed in containers. So it wasn't a problem for packages to require Systemd just for __systemd-sysusers__ to create users. However, in containers, that means a significant size increase.
Auto-detect large size changes
Being able to see what's going on is a prerequisite of implementing any changes. Seeing all the relevant opportunities helps us to focus on the ones having the most impact, and a transparent tracking helps us prove the usefulnes of our work, and to further focus on the most impactful activities.
Besides that, basically all types of deployments benefit from a reduced size, as there is a direct relationship between the installation footprint and attacks surface & relevant CVEs.
**Better understanding** — Yes, we now have much better understanding of the problem and a better, more specific idea about the next steps.
B - If a program is just using a library of systemd, only require systemd-libs.  Example: libusb
C - If a package wants to use systemd-sysusers to create users/groups, only require systemd-sysusers.  (NOTE:  This subpackage isn't implemented yet)
Cloud resources to prototype services. We are not going to change the existing Fedora infrastructure in any way before whatever we develop proves useful and worth the hustle of stabilization and changing production.
Collect specific use cases by talking to people at tech events, internet forums, and any other viable venues.
Context-specific requirements — such as requiring Systemd on traditional deployments being fine vs. requiring it in containers means significant size increases. Leverage weak dependencies in those cases (that might require code changes).
Dependnecies on large things while only using a fraction of the functionality — such as requiring the whole Perl stack to run a single script — such script can be rewritten to Python which is everywhere mostly because of DNF
do performance optimizations for the service to scale well
**Engage with upstream developers** regarding bigger changes in packaging and architecture. An example is Systemd and splitting the __systemd-sysuser__ package.
explore the use of CI and Rawhide Gating
**Extend monitoring services** (Feedback Pipeline) that: