Issue #4008
closedpython-debpkgr does not structure Repositories correcly (in some case)
Description
python-debpkgr (a dependency of Pulp Debian Support) does not structure Debian repositories quite right:
The Debian repository structure (https://wiki.debian.org/DebianRepository/Format) is built from the following schema:
<repo_base_url>/dists/<distribution>/<plain_component>/Packages
<repo_base_url>/dists/<distribution>/Release
Here, <distribution> may contain additional "/" (like "stretch/updates").
Even were components are listed in the Release file as "updates/main", only the "main" part is the "<plain_component>". (slightly simplified.)
However, the debpkgr data structure of the relevant object is built entirely from a <repo_base_url> and a Release file.
Therfore, debpkgr has no way of knowing what the <distribution> part of the paths should be.
It builds the following paths instead:
<repo_base_url>/dists/<Releasefile.codename>/<Releasefile.component>/Packages
<repo_base_url>/dists/<Releasefile.codename>/Release
For most official debian repos this happens to work since <Releasefile.codename>=<distributrion>.
However for debian security the <Releasefile.codename> is for example "stretch" and the <distribution> is "stretch/updates".
The reason we can still synchronize debian security is because <Releasefile.component> happens to be "update/stretch" while <plain_component> is "stetch". (Two wrongs do make a right...)
However the downstream repository in pulp will have a different structure than the upstream Debian repository, making it impossible to reuse this downstream repository as a new upstream repository. In other words, pulp to pulp synchronization is broken.
Related issues
Account for components with an extra path prefix
The components in the repo metadata object ('Release' file) may be prefixed. This prefix must be stripped from certain comparisons. See also: https://wiki.debian.org/DebianRepository/Format#Components
Fixes #4008 https://pulp.plan.io/issues/4008