English Burmese
Specific use cases are defined in Fedora. The community then focuses on those use cases with development and maintenance, optimisation (like minimisation), and testing (like CI and gating). These use cases can be transparently prioritized for infrastructure resources based on community interests.
Sysadmins can easily consume pre-built bits that also get regular updates
**Systemd and containers** — We dag into the issue of Systemd vs. containers, especially for packages requiring it just to create users in containers using __systemd-sysuser__. Working with upstream on splitting the package out. Thought about, but not yet proposed, a wider policy around this.
The problem
Thousands of individual and corporate contributors collaborate in the Fedora community to explore new problems and to build a fast-moving modern OS with a rich ecosystem allowing them to experiment on modernising their infrastructure.
Ticket: https://pagure.io/minimization/issue/13
Unnecessary RPM dependencies (although there probably won't be many)
**Usefulness over size**: There is a balance between the usefulness and size. We take that in mind and will not implement drastic changes that would prevent our users from using Fedora. However, nothing prevents us from producing additional very specific and mininal artifacts.
**Use pcre2 instead of pcre** — The minimization effort is trying to trim
things down to just one pcre, and that is pcre2.
**Using RPM**: We're doing this with RPM. We're not achieving minimization by deleting files after installation. This might be obvious, but still worth mentioning.
Visualize dependencies and a total size for each use case
While Fedora is well suited for traditional physical/virtual workstations and servers, it is often overlooked for use cases beyond traditional installs.
write tests to significantly simplify contribution