• Use common sense.
• When it comes to submissions, anything is fair game, assuming that our policies are followed. However, there is a mild exception for GUI applications.
  • Please refrain from submitting applications that work perfectly fine as a Flatpak, unless there is a technical or UX justification for it. Examples of these exceptions are:
    • Terminal Emulators, as these often only work properly when run directly on the host system.
    • CLI/TUI applications, as the UX of Flatpak isn't optimized for these types of applications. (ex. requiring the user to call Flatpak, and then the RDNN of the app)
    • Applications that may require the user to manually modify its data files regularly (Prism Launcher, other modded game launchers, etc).
    • Applications that suffer major performance or technical issues due to sandboxing (IDEs, text editors, file managers, DAWs and other applications that rely on native plugin support like VSTs or LV2, etc).
    • System components, such as background system services, device drivers or important system configuration tools.
    • Libraries required to build or use the aforementioned packages.
    • Other applications may be excluded as per user demand, at the team's discretion.
• You must have the rights or permission to redistribute the packaged software. Besides that, there is no prohibition on proprietary licenses.
• Submissions must be maintained. We will reject submissions of unmaintained software.
• Submissions must not be malicious.
• Submissions should not conflict with Fedora's own packages.
• Submissions should include an auto-update script.
• Submissions should be placed in the corresponding directory in anda/.
  • Each folder should only contain 1 spec file (recursively).
  • The following directories have a higher priority. Categorize your new package in the following order:
    1. fonts/
    2. system/ (bootloaders, kernels, drivers, ...)
    3. tools/buildsys/ (software used to build other software)
    4. devs/ (tools for software development)
    5. games/
    6. themes/
    7. docker/ (software related to containers)
    8. desktops/ (applications specific to a Desktop Environment)
    9. apps/ (GUI applications)
    10. langs/ (software written in/for a specific programming language)
• Packages must follow our packaging guidelines. When not specified, refer to Fedora's packaging guidelines.
• Low-quality contributions will be declined at the team's discretion.
• Do not include work-in-progress code or untested patches. See https://dont-ship.it/.

Maintenance Policy

• Anyone may make a PR to an already existing package, when doing so, please refer to the submission policies above.
• Unmaintained packages may be removed at any time. Before doing so, we will create a GitHub issue to gauge community interest.
• Terra will only support the latest version of Fedora, if a package doesn't build on the next version of Fedora, we might hold it back.

Naming Guidelines

Prefix/Suffix the packages in the following order (that means nightly fonts should end with -nightly-fonts)

• Nightly packages must end with -nightly.
• Fonts must end with -fonts.
• Libraries should preferably start with lib.
• Packages with names that would conflict with Fedora's packages should be prefixed with terra-. This is usually used for packages that are severely outdated or poorly maintained in Fedora.

Security Policy

Our security policy is documented in the SECURITY.md file.

Code of Conduct

Our code of conduct is documented in the CODE_OF_CONDUCT.md file.

Lifecycle Policy

Our support lifecycle is documented in the lifecycle page.

Packaging Guidelines

Terra uses a slightly different packaging guideline for packages from Fedora's. This article is to outline the specific different guidelines in Terra.

Interpreted Languages (Python, Ruby, etc.)

All packages using interpreted languages follow the traditional Fedora guidelines, with all dependencies must be packaged individually as they are considered runtime dependencies.

Dynamically compiled languages (C, C++, Vala)

Dependencies must also be packaged separately if they are required for runtime.

Statically compiled languages

As Terra does not strictly follow Fedora's reproducibility requirements, and we do not want large amounts of development library languages for them, packagers should vendor dependencies on build time.

Terra's mock sandbox has networking enabled, so builders can download the dependencies directly on build time.

Usages of the mold linker

We encourage the use of mold, which may speed up build times especially in large projects. You may enable it in C/++ projects by adding -fuse-ld=mold in CFLAGS/CXXFLAGS.

Rust

• Do not use the tradtional Fedora %cargo_prep macro. Use %cargo_prep_online from anda-srpm-macros instead, and do not use the %generate_buildrequires macro, as it is useless.
• It is encouraged to use %cargo_license_online and %cargo_license_summary_online, although they are not a strict requirement.
• Avoid using both %cargo_build and %cargo_install in the same spec file as cargo install might cause a rebuild due to a bug. You should only include either one of them. In most cases, you can just omit %cargo_build entirely and it will just build fine.

You can enable mold by using %bcond_without mold.

Example:

%prep
%autosetup -n %{crate}-%{version} -p1
%cargo_prep_online

%build
%{cargo_license_online} > LICENSE.dependencies

%install
%cargo_install

Go

Use the go compiler directly instead of using Fedora's Go macros, as this will generate offline dependencies that we do not want to package. Alternative, use the _online macro variants:

%prep
%goprep
%autopatch -p1
%go_prep_online

%build
%go_build_online %{goipath}

%install
%gopkginstall
install -m 0755 -vd                     %{buildroot}%{_bindir}
install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/

Nim

Use the %nim_prep and %nim_c src/pkgname macros.

add mold as a BuildRequires to enable mold automatically.