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.
3e94ae6f1e
