Software Repositories
Designs for the handling of software repositories.
Goals
- Allow someone to remove a repository that they've added themselves (perhaps by installing a package that contains a repository)
- Allow enabling/disabling special sources that have been preconfigured by the OS vendor
- There could be special predefined software channels that the OS vendor provides, which users might need control over
- Focus on repositories that are distinct collections of content that users can install from - package-based repos, flatpak remotes
- Don't get too technical - the primary use case is a non-technical user who wants to manage their apps
- Try to be transparent - don't stray too far from the logic of each underlying technology
- Don't allow someone to break their system
- Don't allow removing essential repositories
- Try to avoid leaving orphaned software that won't be updated once its parent repository is removed
Non-goals
- This probably isn't the place for switching between channels that are tied to the base OS, such as Atomic branches.
Relevant Art
Discussion
In Software we try and focus on applications rather than random packages of stuff. This is difficult to do with repositories, since we don't know what each one might contain.
We're using the title of "repositories" rather than "sources" to reflect the established terminology for this sort of thing in Linux.
Tentative Design
