As a user I want to sync upstream repositories using "Flat Repository Format"
It appears some APT repositories do not store their release files somewhere beneath a
dists/ folder, using the repo root (or some arbitrary path) instead.
Apparently this repository can be included in an
/etc/apt/sources.list file as follows (at least on Ubuntu):
deb http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/ /
There is some Ubuntu documentation hinting at specifying an "exact path" here: http://manpages.ubuntu.com/manpages/xenial/man5/sources.list.5.html (Also see the examples).
#1 Updated by quba42 about 1 year ago
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
distributionfield, 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
distspath 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.
#4 Updated by quba42 about 1 year ago
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".
#5 Updated by quba42 about 1 year ago
- Subject changed from As a user I want to sync upstream repositories that do not store Release files within /dists/ to As a user I want to sync upstream repositories using "Flat Repository Format"
Needs further discussion:
We could add a separate
FlatAptRemote, or try to use the existing
If we do go for two remotes, a common parent class would probably make sense.
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:
Codenamefield in the Release file.
Architecturesfield in the Release file. (They did add an
Architecturefield that does not contain a valid Debian architecture string...)
Componentsfield 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.
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!
Please register to edit this issue