Adding such an implementation (very close to gnu's) makes me wonder if we
should not simply drop the gnu version parsing from the swh.loader.package.gnu
implementation and push that parsing step within the lister instead (improving
the lister's output with a version field...)In the end, assuming we push the parsing 'version' logic within the gnu lister (D2147),
we can have a sufficientely generic 'tar' loader as the following.
And then define what's the contract needFor more specific use case than gnu's, it can be passed a list of keys to be for behavior-like (oneshotuse to build a composite primary key.
tasks, only tarballs) listers (cf. D2025).
As a first draft, i'd sayThat primary key is solely used to check if we already downloaded the contract is, provide:artifacts or not.
- an origin urlThose default keys are the one needed for gnu origins.
- a list of artifacts: for each of those package artifactsWhen D2025 lands, an url is needed,we will have the choice to either 1. apass along that list of keys for each scheduled tasks.
last modification date,Or 2. at least one hash, and a version
(D2025#inline-14210)even create in this module a dedicated task which set those.
I prefer 1. as it's more explicit.
Related D2147
Related D2025
Related T1389
Depends on D2135