Repositories

From ParabolaWiki
Jump to: navigation, search
Summary
Software repositories contain software compiled and packaged by developers, readily accessible via pacman. This article outlines the official repositories provided and supported by Parabola developers.
Related
Mirrors
Nonsystemd
Nonprism

A software repository is a storage location from which software packages may be retrieved and installed onto a computer system. This article outlines those repositories, which are supported by Parabola and it's package managers: Pacman and Octopi.

1 About Parabola Repositories

Parabola GNU/Linux-libre is a GNU/Linux distribution which is a derivative of Arch for the armv7h (Alarm), i686 (Arch32), and x86 64 (Arch) architectures. Parabola and it's package repositories are fully compatible with Arch (as are Alarm and Arch32); and so the names and precedence of repositories, necessarily correspond to, and align with, their Arch counterparts.

Parabola distributes ONLY free (libre) packages, fulfilling the Free System Distribution Guidelines (GNU FSDG). Parabola's Hackers maintain the libre package repositories, and keep the repositories inherited from the Arch upstream(s) clean of non-free software, in addition to doing any other developer duties. Non-free packages are blocked by your-freedom.

The 'your-freedom' package will help you identify non-free packages that are installed on your system at the time of its installation, as well as protecting you from (accidentally) installing them. Also, if any other non-free package is identified, later updates will ask you for its removal. Bear in mind. that if you want to retain certain non-free packages installed on your system, you'll have to remove your-freedom :).

1.1 Overview

The following tables give a short overview of the different repositories:

Supported
Base
[core] [nonsystemd]
[libre]
[extra] [nonsystemd]
[libre]
Community
[community] [cross]
[kernels]
[libre]
[nonsystemd]
[nonprism]
[pcr]
[multilib] [libre-multilib]
[nonprism-multilib]
Unsupported/Experimental
Testing
[testing] [libre-testing]
[multilib-testing] [libre-multilib-testing]
[community-testing] [kernels-testing]
[nonsystemd-testing]
[nonprism-testing]
[nonprism-multilib-testing]
[pcr-testing]
[KDE-Unstable]
Custom/Third-Party
AUR, git, web, etc [unmaintained]
docker, appimage, snap, flatpak, etc [~HACKER]
(eg: ~aurelien)
pip, gem, npm, etc
curl | sudo bash
  • A blue background indicates repositories inherited/imported from Arch, and filtered through the libre blacklist. These repositories are fully supported.
  • A purple background indicates repositories originating from Parabola. These repositories are fully supported.
  • A red background indicates third-party repositories, with which Parabola is compatible, but their use is discouraged. It is infeasible or impossible to know which software they contain, or which are freely licensed. These repositories are not supported. These are given for expert example. Parabola's only supported package managers (pacman and octopi) can not make use of these types of repositories.
  • Repository names starting with a tilde '~' character, or ending with 'testing', contain experimental packages, preparing but unready, to be integrated into the standard system. These repositories are not supported.

2 Maintaining your pacman.conf

Parabola does not decide which repositories are enabled on any system. repositories are configured in each system's /etc/pacman.conf file; and no Parabola software would ever modify that file without the admin's knowledge. User-friendly tools exist, such as Octopi Repo Editor (octopi), to assist managing your subscribed (enabled) repositories, without needing to edit /etc/pacman.conf manually.

Note: If you edit /etc/pacman.conf manually, be aware that repos are usually declared (subscribed/enabled) as pairs of lines, in the following format:
[REPO-NAME]
Include = /etc/pacman.d/mirrorlist

... where: REPO-NAME is one specific repo (eg: core, libre, nonsystemd). Deleting these line pairs, or commenting them out, unsubscribes (disables) that repository. If there did exist a repository named 'REPO-NAME', it could be disabled like so:

#[REPO-NAME]
#Include = /etc/pacman.d/mirrorlist

Regardless of how repositories are managed, the vertical order in which each appears is critical, for maintaining a sane Parabola system. The repositories described in the "Repositories" section below, are given in a sane order, as the current /etc/pacman.conf.pacnew (from the 'pacman' package) will always be. Most important are the order of [libre], [nonsystemd], and [nonprism]. [libre] must be above [core]; and both [nonsystemd] and [nonprism] must be above [libre]. The *-testing repos are also special. , where the '*' is always the name of another repo. Each of those should appear directly above its main-line counterpart.

Additionally, there are two more essential facts, which every Parabola user should know, at all times, about the system's /etc/pacman.conf.

  • Is [nonsystemd] enabled?
  • Is [nonprism] enabled?

The Standard Parabola System defaults are with both of [nonsystemd] and [nonprism] disabled; though the user-friendly graphical installer (calamares) may have configured differently. Regardless of how the system was initially configured/installed, if either of these essential facts are changed, it is very important to run the following command, before installing/upgrading/uninstalling any packages.

 # pacman -Syyuu
Note: `pacman -Syyuu` is essentially the Parabola "reset" command. It is healthy and harmless, in all normal circumstances.

3 Repositories

All supported Parabola repositories fall into four basic logical categories. The categories and repositories within must be declared in specific order, as given below.

3.1 Parabola Special

The entire "Parabola Special" group must be above/before the "Parabola Standard" group. Repositories in this group must be in the following order:

3.1.1 [nonprism]

The [nonprism] repository can be found in pcr/os/i686, pcr/os/x86_64 or pcr/os/armv7h on your mirror. It is maintained by the Parabola Community and provides packages built and patched without support for non-free, unsafe and dangerous for privacy protocols and services (more info at PRISM ⚡ Break home page). You can find an updated list of removed packages and eventual corresponding replacements at your-privacy blacklist.

Note: This ordering currently prone conflict, although none have yet arisen. There may need to become a [nonsystemd-nonprism] repo someday.

3.1.2 [nonsystemd]

[nonsystemd] is a repository that aims to provide software built and patched to work correctly with init-systems other than systemd. You can find an updated list of removed packages and eventual corresponding replacements at your-initfreedom blacklist.

3.2 Parabola Standard

The entire "Parabola Standard" group must be above/before the "Arch Standard" group. Repositories in this group must be in the following order:

3.2.1 [libre]

The [libre] repository can be found in libre/os/i686, libre/os/x86_64 or libre/os/armv7h on your mirror. Its packages have a complex pkgrel to differentiate between Arch's version and Parabola's version to avoid confusion when migrating (eg: filesystem-2014.07-1.parabola1), but sometimes it's not necessary due which the package doesn't share the same name, like firefox becoming icecat.

The [libre] repository contains four things

  • Replacements for packages in Arch's [core] that were blacklisted
  • Replacements for packages in Arch's [extra] that were blacklisted
  • Replacements for packages in Arch's [community] that were blacklisted
  • Packages produced entirely by Parabola that are deemed to be core packages (and their build dependencies)

[libre] has strict requirements, but currently the sign-off process, where multiple developers vet a package, doesn't reflect this; instead developers are expected to self-review their packages.

In the case of packages being added that aren't replacements for packages from Arch, what belongs in [libre] is just slightly looser than [core], [extra] and [community]. Basically, it is anything which would not be considered as "supplemental", but essential for a healthy Parabola system or Parabola maintenance.

3.3 Arch Standard

3.3.1 [core]

The [core] repository can be found in core/os/i686, core/os/x86_64 or core/os/armv7h on your mirror.

[core] is imported from Arch, but with blacklisted packages removed. In Arch, [core] contains all necessary packages for:

It has fairly strict quality requirements:

  • Developers and/or users need to signoff on updates before package updates are accepted.
  • For packages with low usage a reasonable exposure (as in: inform people about update, request signoffs, keep in testing for a few days up to a week depending on the severity of the change) lack of outstanding bugreports, along with the implicit signoff of the package maintainer is enough).

3.3.2 [extra]

The [extra] repository can be found in extra/os/i686, extra/os/x86_64 or extra/os/armv7h on your mirror.

[extra] is imported from Arch, but with blacklisted packages removed. In Arch, [extra] contains all packages that do not fit in [core]. Example: xorg, Window Managers, web servers, media players, languages like Python and Ruby, and a lot more.

3.3.3 [community]

The [community] repository can be found in community/os/i686, community/os/x86_64 or community/os/armv7h on your mirror.

[community] is imported from Arch, but with blacklisted packages removed. In Arch, [community] contains packages from the AUR that have enough votes and were adopted by an Arch Trusted User.

3.4 Supplemental

The entire "Supplemental" group must be below/after the "Arch Standard" group. The order of repositories within this group are unconstrained, and their package names may collide/conflict.

They are non-standard, non-essential, and user-defined, so conflicts and name-collisions can not be avoided systematically. The one exception is [libre-multilib], which must precede [multilib]; because like the Special and Testing repos above, it may intentionally collide with, and must be able to over-ride, packages in another repo.

3.4.1 [libre-multilib]

The [libre-multilib] repository can be found in libre-multilib/os/x86_64 on your mirror. It is like the [libre] repository but contains 32 bit libraries that can be used to run 32 bit applications in 64 bit installation only.

3.4.2 [multilib]

The [multilib] repository can be found in multilib/os/x86_64 on your mirror. It contains 32 bit libraries that can be used to run 32 bit applications like wine in 64 bit installation.

3.4.3 [kernels]

The [kernels] repository can be found in kernels/os/i686,kernels/os/x86_64 or kernels/os/armv7h on your mirror. It is maintained by the Parabola Community and contains non-standard kernels such as "long term support with stealth TCP sockets patches" kernels oriented towards servers, or kernels compiled with AppArmor, TOMOYO, SMACK and SELinux support.

3.4.4 [cross]

[cross] contains mostly-unsupported packages that contain tool-chains for cross-compiling for a different architecture.

3.4.5 [pcr]

The Parabola Community Repo [pcr] repository can be found in pcr/os/i686, pcr/os/x86_64 or pcr/os/armv7h on your mirror. It is maintained by the Parabola Community and contains free packages that are not included on official repos of Arch Linux. . It also contains packages maintained by Parabola developers, but that are not considered to be essential enough for the base system.

3.4.6 [custom]

This refers to any number of user-defined repositories. The name: 'custom' is not significant. They can have nearly any arbitrary name, though all repo names must be unique within /etc/pacman.conf.

4 Testing

Testing repositories are somewhat special, regarding order. Each should immediately precede it's counterpart (eg: [testing] above [core] and [extra], [libre-testing] above [libre], [community-testing] above [community]). Only some are described here; but their purpose and usage are all analogous.

4.1 [testing]

The [testing] repository can be found in testing/os/i686, testing/os/x86_64 or testing/os/armv7h on your mirror. [testing] is special because it contains packages that are candidates for the [core] or [extra] repositories. New packages go into [testing] if:

  • they are expected to break something on update and need to be tested first
  • they require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into [testing] first and when all rebuilds are done, they are moved back to the other repositories.

[testing] is the only repository that can have name collisions with any of the other official repositories. If enabled, it has to be the first repository listed in your /etc/pacman.conf file.

Warning: Be careful when enabling [testing]. Your system may break after you perform an update with the [testing] repository enabled. Only experienced users who know how to deal with potential system breakage should use it.

The [testing] repository is not for the "newest of the new" package versions. Part of its purpose is to hold package updates that have the potential to cause system breakage, either by being part of the [core] set of packages, or by being critical in other ways.

If you enable testing, you must also enable community-testing and libre-testing.

4.2 [community-testing]

The [community-testing] repository is like the [testing] repository but for packages that are candidates for the [community] repository.

If you enable community-testing, you must also enable testing.

4.3 [libre-testing]

The [libre-testing] repository is like the [testing] repository, but for packages which are candidates for the [libre] repository.

If you enable libre-testing, you must also enable testing.

4.4 [multilib-testing]

The [multilib-testing] repository is like the [testing] repository but for packages that are candidates for the [multilib] repository.

If you enable multilib-testing, you must also enable testing.

4.5 [libre-multilib-testing]

The [libre-multilib-testing] repository is like the [libre-testing] repository but for packages that are candidates for the [libre-multilib] repository.

If you enable any libre-multilib-testing, you must also enable libre-testing.

5 Repositories for the Parabola infrastructure

5.1 [config]

The Parabola project runs one or more servers. There is some documentation about them in the Hacking:Servers page.

Some of the configuration of these servers is handled in packages of the "config" repository. This makes it easier to deploy that configuration to new servers, test it and to contribute to it, etc. For instance it contains the Nginx configuration needed to setup the wiki.parabola.nu wiki.

This repository should contain only public configuration specific to running specific Parabola services like wiki.parabola.nu.

More generic packages like parabola-hackers are currently found in the libre repository instead as for some reasons they might be interesting to users. For instance the parabola-hackers and parabola-hackers-nshd packages can configure a machine to give access to it to the Parabola developers. In some cases that might be useful (for debugging an issue for instance).

6 Unsupported Repositories

Custom/Third-Party repositories, even those distributed by Parabola, are unconstrained and volatile. For example, ~HACKER may be any Parabola team member, past or present. Parabola can not promise any to be functional, or that any will not be deleted, at any time. That is true for most repos (language-specific repos and common git "hubs", for example). This is merely disclosing it plainly and openly (because that's how we roll).

The same applies (most importantly) to any third-party and personal repositories, not distributed by Parabola, but which some program distributed by Parabola is capable of accessing. There are many such tools, and generally, they all should be avoided entirely. Only the Haskell Cabal repository is known to have a libre licensing policy. Each user is solely responsible for use of any custom/third-party repositories.

Parabola specifically and intentionally discourages the use of third-party repositories. Their use may damage your system, or make it difficult for Parabola volunteers to support, and there is little assurance that all software in them is libre. A fully-supported Parabola system is one with all software installed exclusively from the supported Parabola repos.

6.1 AUR

Parabola does not endorse the AUR (Arch User Repository). Often users switching from Arch ask if the AUR is supported in Parabola. Our answer is "no, but it isn't in Arch either." However, it is at least partially endorsed by Arch.

Packages and scripts there are untrusted, and the burden is on the user to inspect the PKGBUILD and resulting package. This is the same in Parabola and Arch. Any packages that you build yourself are, naturally, your responsibility, not Parabola's. Many (most?) of the packages there are of poor quality, and contain incorrect information regarding licenses.

If there is a package in AUR that you would like, you are encouraged to open a package request, so that a Parabola contributor may pick it up and add it to [pcr].

6.2 Experimental

Repositories beginning with a tilde (~) are "user" repositories, and they are provided by individual developers independent of the Parabola project. The individual might be a Parabola developer, but their repository is only supported by them, not the rest of the Parabola team.

That said, the packages in them must still meet the freedom requirements of Parabola. However, they might not meet the quality or stability requirements.

In general, user repositories are being phased out in favor of pcr. However, they aren't going away, or being totally deprecated.

6.3 Unmaintained

[unmaintained] contains detected unsecured (long time) unmaintained packages. It means packages without updates with security vulnerabilities known.

7 Acknowledgement

This wiki article is based on ArchWiki. We may have removed non-FSDG bits from it.