обзор иерархии файловой системы (File system hierarchy overview)
SYSTEM PACKAGES
Developers of system packages should follow strict rules when
placing their files in the file system. The following table lists
recommended locations for specific types of files supplied by the
vendor.
Table 1. System package vendor files locations
┌──────────────────────────┬──────────────────────────┐
│Directory │ Purpose │
├──────────────────────────┼──────────────────────────┤
│/usr/bin/ │ Package executables that │
│ │ shall appear in the │
│ │ $PATH executable search │
│ │ path, compiled for any │
│ │ of the supported │
│ │ architectures compatible │
│ │ with the operating │
│ │ system. It is not │
│ │ recommended to place │
│ │ internal binaries or │
│ │ binaries that are not │
│ │ commonly invoked from │
│ │ the shell in this │
│ │ directory, such as │
│ │ daemon binaries. As this │
│ │ directory is shared with │
│ │ most other packages of │
│ │ the system, special care │
│ │ should be taken to pick │
│ │ unique names for files │
│ │ placed here, that are │
│ │ unlikely to clash with │
│ │ other package's files. │
├──────────────────────────┼──────────────────────────┤
│/usr/lib/arch-id/ │ Public shared libraries │
│ │ of the package. As │
│ │ above, be careful with │
│ │ using too generic names, │
│ │ and pick unique names │
│ │ for your libraries to │
│ │ place here to avoid name │
│ │ clashes. │
├──────────────────────────┼──────────────────────────┤
│/usr/lib/package/ │ Private static vendor │
│ │ resources of the │
│ │ package, including │
│ │ private binaries and │
│ │ libraries, or any other │
│ │ kind of read-only vendor │
│ │ data. │
├──────────────────────────┼──────────────────────────┤
│/usr/lib/arch-id/package/ │ Private other vendor │
│ │ resources of the package │
│ │ that are │
│ │ architecture-specific │
│ │ and cannot be shared │
│ │ between architectures. │
│ │ Note that this generally │
│ │ does not include private │
│ │ executables since │
│ │ binaries of a specific │
│ │ architecture may be │
│ │ freely invoked from any │
│ │ other supported system │
│ │ architecture. │
├──────────────────────────┼──────────────────────────┤
│/usr/include/package/ │ Public C/C++ APIs of │
│ │ public shared libraries │
│ │ of the package. │
└──────────────────────────┴──────────────────────────┘
Additional static vendor files may be installed in the
/usr/share/ hierarchy to the locations defined by the various
relevant specifications.
The following directories shall be used by the package for local
configuration and files created during runtime:
Table 2. System package variable files locations
┌────────────────────┬──────────────────────────┐
│Directory │ Purpose │
├────────────────────┼──────────────────────────┤
│/etc/package/ │ System-specific │
│ │ configuration for the │
│ │ package. It is │
│ │ recommended to default │
│ │ to safe fallbacks if │
│ │ this configuration is │
│ │ missing, if this is │
│ │ possible. Alternatively, │
│ │ a tmpfiles.d(5) fragment │
│ │ may be used to copy or │
│ │ symlink the necessary │
│ │ files and directories │
│ │ from /usr/share/factory/ │
│ │ during boot, via the "L" │
│ │ or "C" directives. │
├────────────────────┼──────────────────────────┤
│/run/package/ │ Runtime data for the │
│ │ package. Packages must │
│ │ be able to create the │
│ │ necessary subdirectories │
│ │ in this tree on their │
│ │ own, since the directory │
│ │ is flushed automatically │
│ │ on boot. Alternatively, │
│ │ a tmpfiles.d(5) fragment │
│ │ may be used to create │
│ │ the necessary │
│ │ directories during boot, │
│ │ or the RuntimeDirectory= │
│ │ directive of service │
│ │ units may be used to │
│ │ create them at service │
│ │ startup (see │
│ │ systemd.unit(5) for │
│ │ details). │
├────────────────────┼──────────────────────────┤
│/run/log/package/ │ Runtime log data for the │
│ │ package. As above, the │
│ │ package needs to make │
│ │ sure to create this │
│ │ directory if necessary, │
│ │ as it will be flushed on │
│ │ every boot. │
├────────────────────┼──────────────────────────┤
│/var/cache/package/ │ Persistent cache data of │
│ │ the package. If this │
│ │ directory is flushed, │
│ │ the application should │
│ │ work correctly on next │
│ │ invocation, though │
│ │ possibly slowed down due │
│ │ to the need to rebuild │
│ │ any local cache files. │
│ │ The application must be │
│ │ capable of recreating │
│ │ this directory should it │
│ │ be missing and │
│ │ necessary. To create an │
│ │ empty directory, a │
│ │ tmpfiles.d(5) fragment │
│ │ or the CacheDirectory= │
│ │ directive of service │
│ │ units (see │
│ │ systemd.unit(5)) may be │
│ │ used. │
├────────────────────┼──────────────────────────┤
│/var/lib/package/ │ Persistent private data │
│ │ of the package. This is │
│ │ the primary place to put │
│ │ persistent data that │
│ │ does not fall into the │
│ │ other categories listed. │
│ │ Packages should be able │
│ │ to create the necessary │
│ │ subdirectories in this │
│ │ tree on their own, since │
│ │ the directory might be │
│ │ missing on boot. To │
│ │ create an empty │
│ │ directory, a │
│ │ tmpfiles.d(5) fragment │
│ │ or the StateDirectory= │
│ │ directive of service │
│ │ units (see │
│ │ systemd.unit(5)) may be │
│ │ used. │
├────────────────────┼──────────────────────────┤
│/var/log/package/ │ Persistent log data of │
│ │ the package. As above, │
│ │ the package should make │
│ │ sure to create this │
│ │ directory if necessary, │
│ │ possibly using │
│ │ tmpfiles.d(5) or │
│ │ LogsDirectory= (see │
│ │ systemd.unit(5)), as it │
│ │ might be missing. │
├────────────────────┼──────────────────────────┤
│/var/spool/package/ │ Persistent spool/queue │
│ │ data of the package. As │
│ │ above, the package │
│ │ should make sure to │
│ │ create this directory if │
│ │ necessary, as it might │
│ │ be missing. │
└────────────────────┴──────────────────────────┘
