Infrastructure/WhatHappenedToPkgdb

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 level agreements (SLAs) and end of life (EOL) dates based on the Fedora release itself. Although the implied SLAs 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 SLAs 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 it's 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 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.

Help/FAQs

How do I give a user commit access to a project?

1. Browse to your project on Pagure over Dist-Git (placeholder link)
2. Click on "Settings"
3. Scroll down to "Users and Groups"
4. Click on "add user"
5. Type the username in the form
6. Select "commit" instead of the default of "ticket" to set the level of access
7. Click "Add"

How do I request a new package, a new branch, or to unretire a package?

The ticketing functionality of PkgDB was replaced by a CLI tool called fedrepo-req. Please review the read me for instructions on how to install and use the tool.

How do I find out who owns a package?

1. Browse to the project on Pagure over Dist-Git (placeholder link) you are interested in
2. On the right side of the page, there is a heading called "Contributors". Under that heading, there will be a username with "(main admin)" displayed next to it. That is the owner of the package.

How do I find out the list of orphaned packages?

All orphaned packages will be owned by the "orphan" FAS user account in Pagure over Dist-Git (placeholder link).

You may use the user interface to view all the projects owned by the "orphan" user, but this will include projects other than just packages: [1]

You may use the REST API to view all the orphaned RPM packages by visiting: https://src.fedoraproject.org/pagure//api/0/projects?namespace=rpms&owner=orphan

How do I find the list of retired packages/branches? (incomplete)

Retired branches are tracked in PDC by setting the "active" flag to "false" on a branch.

To view all packages with a master branch that is retired, you can visit the following: https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=false&type=rpms&name=master

To view all retired package branches, you can visit the following: https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=false&type=rpms

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 SLAs?

A branch's SLA is 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 wanted to view the Python package's SLAs 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

How do I find what SLAs are available for use?

All available SLAs are defined in the Product Definition Center (PDC) at: https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/

How do I set an SLA on my branch? (TODO)

TODO

Will there be an "f27" branch? (unofficial response; needs confirmation)

Yes, there will be an "f27" branch that will in general act like the "f26" branch with SLAs that match the Fedora 27 release. This means packagers don't have to change their branching strategy if they don't want to. With that being said, 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.