-
Notifications
You must be signed in to change notification settings - Fork 484
Distribution Support
The whole feature sits behind the :enhanced_distribution_support feature toggle.

The organisation that publishes distributions — openSUSE, SUSE, Debian.
A Vendor belongs to exactly one Project, and a Project has at most one Vendor. That project is the vendor's home in OBS and the source of all authorization for the subtree beneath it.
Distro is a product line published by a vendor. For example Leap, Tumbleweed, SLES, Debian.
Names are unique per vendor, not globally, so two vendors may both ship something called "Micro".
A distro release is a specific shipped version of a distro. For example Leap 15.6, SLES 15 SP6, Debian 13.
The join model that says what a release is actually made of. A release links to many RepositoryArchitecture's, and one RepositoryArchitecture may serve many releases.
OBS already has a Distribution model, and the new hierarchy deliberately does not reuse or extend it. The two solve different problems:
Distribution (legacy) |
Distribution Support | |
|---|---|---|
| Shape | Flat — vendor is a string column on each row |
Three linked models |
| Ownership | Admin-only (DistributionsController restricts create/update/destroy) |
Project maintainers, via the policy chain |
| Purpose | Populates the "Add repository" wizard | Describes what a vendor ships, and what it is built from |
Note the naming: the new model is Distro, not Distribution, precisely so the two can coexist. There is no namespace involved; the class names are distinct.
This is easy to get wrong in either direction.
Not projects. The obvious framing is "a release is a set of projects". This cannot express reality, because projects are shared across releases. openSUSE:Maintenance feeds several Leap versions simultaneously. Given only a project, there is no way to say which release a given piece of content belongs to.
Not repositories alone. Repository is still a set of architectures, and a release does not necessarily ship all of them. A repository may build x86_64, aarch64 and i586 while the release in question only ships the first two.
- Development Environment Overview
- Development Environment Tips & Tricks
- Spec-Tips
- Code Style
- Rubocop
- Testing with VCR
- Test in kanku
- Authentication
- Authorization
- Autocomplete
- BS Requests
- Events
- ProjectLog
- Notifications
- Feature Toggles
- Build Results
- Attrib classes
- Flags
- The BackendPackage Cache
- Maintenance classes
- Cloud uploader
- Delayed Jobs
- Staging Workflow
- StatusHistory
- OBS API
- Owner Search
- Search
- Links
- Distributions
- Distribution Support
- Repository
- Data Migrations
- Package Versions
- Rails Update
- Ruby Update
- Updating-rake-or-rack
- Brakeman
- Run OpenQA smoketest locally
- Factory Dashboard
- Responsive Guidelines
- osc
- Importing database dumps
- Problem Statement & Solution
- Kickoff New Stuff
- Mob-Programming Sessions
- New Swagger API doc
- Documentation and Communication
- GitHub Actions
- Setup an OBS Development Environment on macOS
- Remote Pairing Setup Guide
- How to Introduce Software Design Patterns
- Query Objects
- Services
- View Components
- RFC: Core Components
- RFC: Decorator Pattern
- RFC: Backend models
- RFC: Hotwire Turbo Frames Pattern