Debian Support

Some initial thoughts:

• We need to make sure the solution does not break any existing use cases.
• If there is no unambiguous way to handle these new cases using the existing distribution field, then we need a new field/option in our remotes. (use this as a last resort)
• We need to make sure we consider every instance of hard coded dists path segments in our solution.
• The exception is the simple publisher which generally ignores upstream repo structure in favour of its own.
• How should the structured publisher deal with so structured repos? (It probably needs to stay true to its word and retain upstream Release and Packages file placement.)
• We will need to think about fixtures and tests for this.
• I consider this to be a new feature, not a bugfix.

It appears Debian has a specification for this as well: https://wiki.debian.org/DebianRepository/Format#Flat_Repository_Format

They refer to this as a "Flat Repository Format".

Note:

Thought this issue is nearing completion, the example repository in the ticket description won't become synchronizable with this change!

That repository has multiple issues that are independent of it being in flat repository format:

• No Codename field in the Release file.
• No Architectures field in the Release file. (They did add an Architecture field that does not contain a valid Debian architecture string...)
• No Components field in the Release file.
• The metadata references packages that don't actually exist. (This can be worked around by using policy="on_demand" in the remote).

Since APT is nevertheless willing to consume this repository, we might look into opening separate issues to support these corner cases.

Example repo:

deb http://developer.download.nvidia.com/compute/cuda/repos/debian10/x86_64/ /

Worst repository ever! (For good measure the public key needed to verify the repository is published right there in the repository...)

If we can get this repository to synchronize, we can synchronize anything!