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

224/10000 · 224

This translation is currently locked.

English Actions
The most straightforward way to provide an extra is with a dedicated subpackage containing no files (a "metapackage"). This case can be automated with the `+%python_extras_subpkg+` macro.
Alternative approach: when some extra is always useful in a distro, it can be provided by the main package; when several extras are related, they may be provided by a single subpackage. However, having one dedicated subpackage per extra allows you to use the automatic dependency generator to ensure that the extras' requirements will stay in sync with upstream. If you create a dedicated subpackage and want it to be always/usually installed, you MAY Require/Recommend/Suggest it from the main package.
The dependency generator for extras activates if the following holds:
The package must contain the `.egg-info`/`.dist-info` directory, usually as `+%ghost+`.
The package name must end with `+EXTRA` (where `EXTRA` is the extra name).
As an example, the extra subpackage for `+requests[security]+` can be specified using the `+%python_extras_subpkg+` convenience macro as follows. The macro takes the main package name and name(s) of the extra(s) as well as path to the `.egg-info` or `.dist-info` directory:
%{?python_extras_subpkg:%python_extras_subpkg -n python3-requests -i %{python3_sitelib}/*.egg-info security}
For this case, the extras dependency generator will read upstream metadata from the `.egg-info` directory. If it finds that the `security` extra has a dependency on `cryptography`, it will generate `+Requires: python3.Xdist(cryptography)+`, `+Provides: python3dist(requests[security])+` (and the corresponding `+python3.Xdist+` variant).
If you need additional features that the `+%python_extras_subpkg+` macro does not cover, you will need to write the subpackage sections manually. Such features can be, for example:
Obsoleting/providing other names (e.g. obsoleted extras packages)
Manual strong or weak dependencies on other (possibly non-Python) packages
Including files excluded from the main package (if such files only make sense with the extra and the base package does not fail without them)
As an example of what you need to write in these cases, the `+%python_extras_subpkg+` macro invocation above expands to the following:
%package -n python3-requests+security
Summary: Metapackage for python3-requests: security extras
Requires: python3-requests = %{?epoch:%{epoch}:}%{version}-%{release}
%description -n python3-requests+security
This is a metapackage bringing in security extras requires for python3-requests.
It contains no code, just makes sure the dependencies are installed.
%files -n python3-requests+security
%ghost %{python3_sitelib}/*.egg-info
Note that the dependency generator does not add a dependency on the main package (the `+Requires: python3-setuptools_scm = ...+` above). If you are not using the `+%python_extras_subpkg+` macro, you need to add it manually.
The `+%python_extras_subpkg+` can take multiple extras names to generate multiple packages. For more options, see the https://fedoraproject.org/wiki/Changes/PythonExtras[change proposal which introduced this].
Provides
For any module `foo` intended to be used in Python 3 with `import foo`, the package that includes it *should* provide `python3-foo`. This is of course always the case if the subpackage is named `python3-foo` (as in the examples below). If the subpackage has some other name, then `Provides: python3-foo` should be added explicitly (via `+%py_provides python3-foo+`, see below).
The %py_provides macro
All packages that provide `+python3-...+` (for any `+...+`) SHOULD also provide `+python-...+` and `+python3.X-...+`. Starting from Fedora 33, most of the Python packages named `+python3-...+` will provide such names automatically via the dependency generator in `/usr/lib/rpm/fileattrs/pythonname.attr`.
Any manually added virtual provides of `+python3-...+` SHOULD be done via the `+%py_provides+` macro.
Instead of:
Provides: python3-pkg_resources = %{version}-%{release}
Do:
%py_provides python3-pkg_resources
Optionally, supply a custom `epoch:version-release` as a second argument to `+%py_provides+`.
On releases older than Fedora 33, or (for technical limitations) for packages without files, it is necessary to use `+%py_provides+` even for package names:
%package -n python3-%{srcname}
Summary: %{summary}
%py_provides python3-%{srcname}
Packagers SHOULD try to remove explicit `+%py_provides+` calls for package names, but MAY preserve them if they aim for compatibility with older releases or packages without files.
Historically, there was `+%python_provide+` macro with similar but different semantics. It still works for compatibility reasons but it is deprecated and SHOULD NOT be used and packagers SHOULD replace is with appropriate `+%py_provides+` call.

Loading…

No matching activity found.
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.

8316135 String information

Source string description
type: Plain text
Flags
read-only
Source string location
./pages/Python_201x.adoc:222
String age
3 years ago
Last updated
a year ago
Source string age
3 years ago
Translation file
pot/master/pages/Python_201x.pot, string 57