lgtm, one question inline.

Well, wrong forge to push diff.
Fixing that in our gitlab instance [1].

After discussing D8833 and discussing the general API with @olasd, it feels like adding a delete method to swh.journal.writer.interface.JournalWriterInterface is the wrong approach. To try to capture our discussion

Build is green

Rebase

Build is green

Rebase

Looks good to me, thanks !

Build is green

• Fix license headers
• Fix test cases to match Fedora lister output

@KShivendu , before landing this please fix the year in some license headers and update tests to match fedora lister output.

Build is green

• Use intrinsic version (and other suggestions by @anlambert)
• Update tests for the same

@KShivendu Hi, we had a similar situation with rubygems loader, see its _load_directory method

@KShivendu , we are almost in a landable state for the RPM loader.

Build is green

• Rebase against master

I have a question: The .tar files obtained from this have a contents.tar.gz which contains the real source code. Is there a way to extract this internal .tar file using the current tar loader?

Thank you!

Build is green

Amend impacted docstrings

Build is green

Build is green

Adapt according to discussion

Update commit message

The issue comes from the fact that the webapp gets the release names from the release objects of our data model and not
from the branch names targeting releases in associated snapshot object.

Build is green

• Rebase against master

In D8386#229912, @olasd wrote:

In D8386#229890, @anlambert wrote:

In D8386#229882, @olasd wrote:

In D8386#229677, @KShivendu wrote:

@anlambert

I noticed that https://archive.softwareheritage.org/browse/origin/directory/?origin_url=deb://Ubuntu/packages/nginx has duplicate branch names, which is very confusing. In fact, even the default branch is repeated twice and I see two check marks. If we use branch names like 0.3.9-15.fc26, won't the same happen with Fedora listers? It doesn't seem to differentiate between the editions. (or does it?)

This seems like a misfeature in the webapp:

https://archive.softwareheritage.org/api/1/snapshot/158a3f36b0bd3da461fb7458de44cfa2c94e4270/

The snapshot has multiple branches, with the same version suffix, pointing at the same objects (because the exact same version of the package is present in multiple Ubuntu suites).

I'm not 100% sure how we should be fixing that, but that bug shouldn't prevent you from giving the fedora snapshots the "semantically correct" structure.

I also noticed that yesterday evening and I was also wondering what is the best way to fix that. I see two possible options:

1. We change the names of the keys in snapshot branches dictionary in order to use the intrinsic version of a debian package instead of its extrinsic one (meaning releases/bionic-security/main/1.14.0-0ubuntu1.10 should rather be releases/1.14.0-0ubuntu1.10)
2. We update the webapp to filter duplicated releases before display as the release name is used instead of the snapshot branches key associated to the release

I would rather go for the second one as keeping the debian/ubuntu suites and components in keys of snapshot branches dictionary seems of interest.
We could do the same for the fedora case as based on my tests it is quite common that extrinsic versions in the form [0-9].[0-9].[0-9]-[0-9].fc[0-9]+
target the same intrinsic version [0-9].[0-9].[0-9]-[0-9].

We should move this branch (ha) of discussion to a separate task. I would really want us to keep (and display) the information about what suites have been detected to contain what package.

How does the webapp get the release name showed in the menu? From the release object, or from the branch name?

I think it would make sense to display the branch name after the release name, if it didn't match the usual refs/tags/$(release name) pattern