Sunday, March 13, 2022

[SOLVED] How does APT decide which "binary-" directories to look in?

Issue

Using a Raspberry Pi, I am trying to use a newer version of puppet than the provided 2.7 by adding the puppetlabs repository, which has no 'binary-armhf' folders. (For non-Raspbian users - Raspbian is wheezy-based.) This repository is structured as follows:

  • dists
    • hardy
      • ...
    • ...
    • wheezy
      • dependencies
        • ...
      • main
        • binary-all
        • binary-amd64
        • binary-i386
        • source

My expectation is that APT should, on seeing that there is no main/binary-armhf directory (in the wheezy/Release file), fall back to main/binary-all; instead, apt-get update prints an error

W: Failed to fetch http://apt.puppetlabs.com/dists/wheezy/Release  Unable to find expected entry 'main/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file)

and apt-cache madison puppet does not show any binary packages (only source) as available for installation from apt.puppetlabs.com.

From inspecting other packages correctly installed from the default repository, apt on this platform seems to accept 'all' as an architecture for packages that happen to be listed in a binary-armhf/Packages file; however, it seems not to accept 'all' as an architecture when looking for a Packages(.gz) to download.

To the actual questions:

  1. Are there any clients that actually consider their own architecture to be 'all'?
  2. Is there a way to configure APT to check main/binary-all in addition to main/binary-$native_arch? EDIT: There is (using the deb [arch=all] in sources.list) - but it's not clear if this is always safe to do. (e.g. if you say [arch=i386], does it make your system think it can install i386 packages, or will it just fetch the Packages list?).
  3. If neither of the above answers is yes, what's the intended utility of a main/binary-all release that no clients will actually fetch?

Solution

Apt printed only warning (W:), not error. The Release file contains only checksums of other index files. binary-all is for architecture independent packages, like those written in perl or python.

I suppose the Packages file should correctly specify where to look for binary package. I have chacked it and the puppet package seems to be specified in binary-all/Packages file. But the main problem is probably that aptitude doesn't allow you to use any packages from repository which doesn't know your architecture. Maybe empty binary/arm-hf/Packages file + mention of arm-hf in Architectures: i386 amd64 all in Release file would suffice. Until then, you have to manually download the .deb files and install them using dpkg -i.

Now your 3 questions: I would say that no client has architecture "all" by default. APT does check also the "binary-all" directory, but it probably cannot live without repository which knows its architecture. Speaking of that, the workaround with [arch=all] should work, but I would not try it with anything else than "all".

Here is a document about the format of debian repositories Debian Repository Format.



Answered By - Marki555
Answer Checked By - Cary Denson (WPSolving Admin)
at