The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not update the repository.
Zen

Source string Source string

239/10000 · 239

This translation is currently locked.

English Actions
%prep
%setup -q
%ifarch s390x
%patch0 -p1
%endif
Filesystem Layout
Fedora follows the https://refspecs.linuxfoundation.org/fhs.shtml[Filesystem Hierarchy Standard] with regards to filesystem layout, with exceptions noted below. The FHS defines where files should be placed on the system.
Fedora allows cross-compilers to place files in `+/usr/target+`.
Fedora does not allow new directories directly under `+/+` or `+/usr+` without FPC approval.
Libexecdir
The https://www.pathname.com/fhs/[Filesystem Hierarchy Standard] does not include any provision for libexecdir, but Fedora packages MAY store appropriate files there. Libexecdir (aka, `+/usr/libexec+` on Fedora systems) should only be used as the directory for executable programs that are designed primarily to be run by other programs rather than by users.
Fedora's rpm includes a macro for libexecdir, `+%{_libexecdir}+`. Packagers are highly encouraged to store libexecdir files in a package-specific subdirectory of `+%{_libexecdir}+`, such as `+%{_libexecdir}/%{name}+`.
If upstream's build scripts support the use of `+%{_libexecdir}+` then that is the most appropriate place to configure it (e.g., passing `+--libexecdir=%{_libexecdir}/%{name}+` to autotools configure). If upstream's build scripts do not support that, `+%{_libdir}/%{name}+` is a valid second choice. If you have to patch support for using one of these directories in, then you should patch in LIBEXECDIR, preferably configurable at build time (so distributions that do not have `+/usr/libexec+` can set LIBEXECDIR to another directory more appropriate for their distro).
Multilib Exempt Locations
If a package is exempt from multilib, it may use `+%{_prefix}/lib+` instead of `+%{_libdir}+`. Packages that contain architecture specific files that would ordinarily be installed into `+%{_libexecdir}+` are always considered ineligible for multilib. However, you should be sure that the (sub)package that they are in does not have other content that would be considered eligible for multilib. If this is not the case for the files you wish to do this in for your package or you are just unsure, ask FESCo for an explicit multilib exemption.
`+/run+`
System services should store small volatile run-time data in `+/run+`. This is a tmpfs backed directory that is mounted in very early boot, before any services are started (and before `+/var+` is available). `+/var/run+` is a legacy symlink to `+/run+`.
No Files or Directories Under `+/srv+`, `+/usr/local+`, or `+/home/$USER+`
The https://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM[FHS says]:
"...no program should rely on a specific subdirectory structure of /srv existing
or data necessarily being stored in /srv. However /srv should always exist on FHS
compliant systems and should be used as the default location for such data.
Distributions must take care not to remove locally placed files in these
directories without administrator permission."
The FHS is explicitly handing control of the directory structure under `+/srv+` to the system administrator rather than the distribution. Therefore, no Fedora packages can have any files or directories under `+/srv+`, come preconfigured to use specific files or directories under `+/srv+`, to remove files there, or to modify the files there in any way.
In addition, no Fedora package can contain files or directories or modify files under:
`+/usr/local+` as these directories are not permitted to be used by Distributions in the FHS
`+/home/$USER+` as users can arbitrarily modify the files in their home directories and rpm packages that modify those files run the risk of destroying user data. Additionally, sites may be nfs mounting `+/home+` on many different types of systems or even network automounting them on demand. Modifying files in home directories that are thus configured will have negative effects in both of these situations.
It is important to note that the software in a Fedora package, once installed and configured by a user, can use `+/srv+` as a location for data. The package simply must not do this out of the box
Limited Usage of `+/opt+`, `+/etc/opt+`, and `+/var/opt+`
`+/opt+` and its related directories (`+/etc/opt+` and `+/var/opt+`) is reserved for the use of vendors in the FHS. We have reserved the `+fedora+` name with https://www.lanana.org/lsbreg/providers/providers.txt[LANANA] for our use. If a package installs files into `+/opt+` it may only use directories in the `+/opt/fedora+` hierarchy. Fedora attempts to organize this directory by allocating a subdirectory of our `+/opt/fedora+` directory for specific subsystems. If you think you need to use `+/opt/fedora+` please file an FPC ticket to decide whether it's a valid use of `+/opt+` and what subdirectory should be allocated for your use.
Currently, we have allocated `+/opt/fedora/scls+`, `+/etc/opt/fedora/scls+`, and `+/var/opt/fedora/scls+` for use by {scl-guidelines}.
Because the Google-supplied Chrome packaging has chosen a specific file location for extension-specific files which, if used, would conflicts with the above guidelines, the Packaging Committee has approved the following exception: A package MAY install files into the `+/etc/opt/chrome/native-messaging-hosts+` directory, and may create that directory hierarchy, as long as package as a whole also supports Chromium. (The Chromium support MAY be in a different subpackage.) If Chrome in the future allows a more standard directory to be used for this purpose, this exception will be removed.
Merged file system layout
Fedora has merged several directories that historically used to be separate.
|Path|Merged with|RPM Macro

|`+/bin+`
|`+/usr/bin+`
|`+{_bindir}+`

|`+/sbin+`
|`+/usr/bin+`
|`+%{_bindir}+`

|`+/usr/sbin+`
|`+/usr/bin+`
|`+%{_bindir}+`

|`+/lib64+` or `+/lib+`
|`+/usr/lib64+` or `+/usr/lib+`
|`+%{_libdir}+`

|`+/lib+`
|`+/usr/lib+`
|`+%{_prefix}/lib+`
For example, end users will find that `+/bin/sh+` is the same file as `+/usr/bin/sh+`, and `+/usr/sbin/sendmail+` is the the same as `+/usr/bin/sendmail+`.
However, rpm file dependencies don't work according to what's on the filesystem, they work according to the path specified in the rpm `+%files+` section. So an rpm which specified:

Loading…

User avatar None

Source string added
"...no program should rely on a specific subdirectory structure of /srv existing
or data necessarily being stored in /srv. However /srv should always exist on FHS
compliant systems and should be used as the default location for such data.
5 years ago
Browse all string changes

Things to check

Ellipsis

The string uses three dots (...) instead of an ellipsis character (…)

Reset

Glossary

English English
No related strings found in the glossary.

1001453 String information

Source string description
type: delimited block .
Flags
no-wrap, read-only
Source string location
./pages/index.adoc:582
String age
5 years ago
Last updated
a year ago
Source string age
5 years ago
Translation file
pot/master/pages/index.pot, string 113