see also T22

We should make sure our abstraction works for things where the original artifact has several files (e.g. a debian source package)

A few proposals:

The most generic approach is linking a virtual "directory" containing all the original artifacts, complete with their names/relative paths, to the directory resulting of the artifact unpacking.

• Pros : this lets us reference arbitrarily complex original artifacts, and reuses our already-existing "directory" abstraction as a "set of named files".
• Cons : this makes us generate "dangling" directories and complexifies the single-original-artifact case (e.g. tarballs).

A more ad-hoc approach is creating an "original artifacts" table with the following columns (and one entry per file in each original artifact):

• uncompressed directory
• original artifact (content / skipped_content id)
• original artifact relative name

• Pros: doesn't clutter our directory/directory entry table
• Cons: less code reuse for the original artefact import

This naive schema breaks when several original artifacts yield the same directory, so we probably need to add an "original artifact id".

We could do a hybrid approach where an original artifact could either be a content (single-file original artifact) or a directory (multi-file original artifact).

We're settling on a new table:

original_artifact

• id bigserial primary key
• directory sha1_git references directory(id)
• type enum ('archive', 'dsc', ...) // ?

original_artifact_content

• id bigint references original_artifact(id)
• content sha1_git // sha1_git is not the primary key for content/skipped_content. chosen for consistency with directory_entry_file's foreign key, could use sha1 instead.
• path bytea

We would register each directory produced by an original artifact in the original_artifact table.

Each file from the original artifact would be registered in our current content tables (currently, with an 'absent' status) if it doesn't exist yet. It would then be associated to the directory by adding an entry in original_artifact_content, with its relative path (we need to register the path for composite artifacts).

We could also merge the two tables into a single one.