Why PkgDB Is Being Decommissioned

In general, PkgDB works well for the current workflow of a package’s lifecycle. Currently, a package has several branches that are tied to Fedora releases such as “f24” or “f25”. These branches have implied service levels (SLs) and end of life (EOL) dates based on the Fedora release itself. Although the implied SLs and EOLs in these branches have worked well for Fedora in the past, it’s becoming increasingly difficult to juggle different application lifecycles and their dependencies’ lifecycles under the umbrella of these limited number of SLs and EOLs, especially when trying to keep up with upstream. In the past, we have not been able to have different package lifecycles within a Fedora release due to the nature of its design. With Modularity, that will become a reality, and Fedora packagers and module maintainers will need a new way of branching in dist-git to enable this functionality.

Since PkgDB was written with the old way of branching in mind, there ended up being two logical paths forward. We could significantly rewrite PkgDB to work with the new branching methodology, or we could migrate PkgDB's existing functionality to other tooling. After talking with some folks in the Fedora community, the latter seemed to be the right approach because Fedora was moving to "Pagure over Dist-Git", and that was going to duplicate and clash with a lot of PkgDB's functionality anyways.

How Is PkgDB's Functionality Being Replaced?

PkgDB has two primary functions. It provides package repo ACLs, and package related "admin requests" and "admin actions". After PkgDB will be replaced, ACLs will be handled in Pagure over Dist-Git (placeholder link) at the package level like you would handle a traditional code repository on pagure.io. As for "admin requests" and "admin actions", those will be replaced by a CLI tool called fedrepo-req (see: a demo) that will submit JSON formatted tickets on your behalf to a ticket queue in a specific Pagure project monitored by the Fedora Release Engineering group.

For more information on this or information on how other features in PkgDB are being replaced, please read the "How To Make This Change" section of the Arbitrary Branching Focus Document written by the Factory 2.0 team.

To view all retired packages, a script will need to be written to query PDC and perform a process of elimination.

How do I find a branch's SLs?

A branch's SLs (termed SLA in PDC) are stored in the Product Definition Center (PDC). An entry in PDC is required for a package to be used in a module. As an example, if you wanted to view the Python package's SLs for the 2.7 branch, you can visit the link below. You'll notice that the URL contains three parameters to the request. The "type" is set to "rpms", which filters the request down to just RPM packages. The "global_component" is set to "python", which filters it down to only branches belonging to any "python" component (e.g. an RPM, container, module, etc). Lastly, the "name" is set to "2.7, which filters it down to only "2.7" branches of components. All these filters together give you a unique result of the Python 2.7 RPM branch.
https://pdc.fedoraproject.org/rest_api/v1/component-branches/?type=rpms&global_component=python&name=2.7

Will there be an "f27" branch?

Yes, we will automatically create an "f27" branch that will in general act like the "f26" branch but with explicit SLs that match what we would expect from the implicit SLs of a traditional Fedora 27 release. This means packagers don't have to change their branching strategy if they don't want to. For f28, we intend to propose to FESCo that we do not create global "f28" branches for all packages.

(If one branch is suitable for multiple Fedora releases, it may be less work for the packager to create a single branch that is used by all those releases instead of maintaining a branch per release. To arrive at this scenario, at some point we have to stop automatically creating new branches for new distro releases.)

In what circumstances should I request a new-style branch?

For context, go back to review Changes/ArbitraryBranching. Traditional Fedora dist-git branches are named in correspondence with a release of the distro. "New-style" branches allow packagers to name a branch "arbitrarily". See advice on choose a name in the next subsection.

There could be many reasons to request a new-style branch. The primary reason is if you'd like a branch that doesn't have an SL of a traditional Fedora release. If for instance, you create a branch that can serve multiple Fedora releases, that would end up being less work for you as the packager since you only maintain one branch instead of many with the same code base. Another instance is if your package needs to have breaking changes that are frequent and violate the lifecycle of a traditional Fedora release. The latter example could not, however, be included in a Fedora release since it's SL is lower than the SL of a release.

How should I name my branch?

At this time, there are no restrictions on how you name your branches except that they may not be derogatory or offensive; they may not violate the Fedora Community Code of Conduct.

Try to use branch names that best describe the SL you are trying to provide. For instance, if you maintain a package that is at version 2.7 for a while, you could create a branch called "2.7" which would be updated with every 2.7.x release upstream. Another example is if you are always trying to package the latest upstream version, you could call your branch "latest". It's really up to you, but just try to be informative and considerate when choosing names.

Requests for new branches will still pass through a member of the 'cvsadmin' group for approval. They may adopt more specific policy over time.

How do I pick an SL for my branch?

See this section of the Module guidelines for information on selecting the appropriate SLs.