Score:0

Determine available architectures of an apt repo without adding as a source

us flag

When working with deb (apt) package repos, you can sometimes browse them over http to determine what is available across different architectures (amd64, arm64, etc). For example, Ubuntu gives a file listing to help browse the repo

However, other sources, such as this Elastic repo, do not allow regular browsing.

My only option appears to be actually adding the repo to my sources (make modifications to my system):

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list

After adding, running apt update confirms the repo offers arm64 packages (since I'm on an arm64 host):

Get:7 https://artifacts.elastic.co/packages/7.x/apt stable/main arm64 Packages [78.8 kB]

However, I want to confirm ALL available release architectures offered by the repo AND I want to do it without having to modify my host system. How can I do that?

In this use-case I had to spin up a test arm64 host just to determine if the packages were available. I would really like to avoid having to do that type of thing in the future and just browse the repo offerings remotely.

Nikita Kipriyanov avatar
za flag
You can download the [repo's index files](https://wiki.debian.org/DebianRepository/Format) and view them. The file "$REPO_BASE/dists/$DIST/InRelease" contains an architecture information. I think this is what Ubuntu does.
Rino Bino avatar
us flag
@NikitaKipriyanov Thanks for the response. Understood that some repos allow you to check the release and browse the repo, but this question is about repos that don't allow file browsing such as the Elastic repo referenced in the original question.
Score:2
za flag

You don't need to browse the repo as a directory. Knowing all the repo properties (from the string you use to add the repo), you are guaranteed to know the precise URL (a direct link) of the release file. Then you download it, and it's a text file with a list of essential repository information. The structure of a repository and its control files is explained in the wiki.

You'd start with the file $REPO_BASE/dists/$DIST/InRelease. These REPO_BASE and DIST are determined from your line in sources file:

deb https://artifacts.elastic.co/packages/7.x/apt stable main
#   REPO_BASE                                     DIST   COMPONENT

In this case, release file has the following direct url: https://artifacts.elastic.co/packages/7.x/apt/dists/stable/InRelease. It contains list of other repository files, including Contents and Packages files for each architecture.

Each Packages file is a text file with descriptions of all packages in the repo for the component. For instance, https://artifacts.elastic.co/packages/7.x/apt/dists/stable/main/binary-arm64/Packages lists all ARM64 binary compiled packages for your repo. The formula for the link is $REPO_BASE/dists/$DIST/$COMPONENT/binary-$ARCH/Packages.

And then, you can also calculate the link to each deb file in the repo. Each package in the above Packages file has a Filename item. You'd build the deb link using the formula: $REPO_BASE/$Filename. For example, for the packetbeat it happens to be https://artifacts.elastic.co/packages/7.x/apt/pool/main/p/packetbeat/packetbeat-7.8.0-arm64.deb.

This is exactly the way Apt itself works, and this is the way Ubuntu's utility you mentioned works.


Disabling directory listing on the Debian repository is silly. The sole reason for existence of the repository is exactly to provide that information, so disabling another human-convenient way to see it is beyond my understanding.

Rino Bino avatar
us flag
Thanks, navigating to the InRelease file directly works.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.