3e94ae6f1e
I was looking into a question posed in one of the Fedora discussion threads: is it OK for a package to assume that files in different directories under /usr are always on the same mount point? rpmlint emits a warning if a package has files that are hardlinked between directories, i.e. rpmlint thinks that this is not the case. But in practice, our systems are like this and our tooling generally doesn't expect a part of /usr to be separated out. I looked at the MOUNT_REQUIREMENTS document, but it doesn't answer this question clearly. It was clearly written with the assumption that e.g. "/usr/" or "/var/" are one mount point, so when it is "mounted", all of it is available. But the document also talks about submounts being pulled in through requirements on specific units, which requires some mounts not to be mounted all at once, so the reader is left without any direct answer to this question. This rewrite makes the following changes: - rename "generally three categories of requirements" to "three general categories of mount points" because we're categorizing mount points, not requirements. - always repeat the category name in further mentions, e.g. "2/early" instead of just "2" so the reader doesn't have to jump back to the table when reading. - mention that it is OK for a mount point to be not split out - say that submount which is "conceptually separate" may be mounted later. - say "ephemeral system" instead of "stateless system" and split out the description of those systems into a separate paragraph and clearly state that they are an exception that skips the requirements listed in this document. - be consistent in specifying the boundary before which each category must have been mounted. Previously, cat. 1 was described as "before transisition" and cat. 2 was described as "during early boot", which created the additional problem that later we needed to contradict this saying that "must be mounted during early boot" doesn't actually mean that and this can be done ealier. If we say "before end of early boot", we avoid this awkwardness.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS