I'm wondering if we should keep this note; would this be a common situation? Perhaps we should keep this as an exercise for the "advanced user", as it would likely not be a standard situation.

Reason why I'm leaning towards removing it, is that the "notes" (targeting non-standard situations) now take up more space than the actual instructions for the "standard" case;

If we do think it's useful, perhaps we should move it inside each tab, and as a "non note", e.g.

The instruction above automatically configures the package repository for your
machine's native architecture. If you want to install Docker for a foreign
package architecture, replace `$(dpkg --print-architecture)` with the desired
architecture, such as `armhf` or `arm64`.

As stated above, IMO the "arch=" tag could be removed, leaving it up to DPkg to simply pull the native architecture of the installed OS/distro. Especially with dpkg --print-architecture the outcome should be exactly the same. If someone has some special setup, where parts of the system intentionally consists of different architecture binaries, one must have known about that "arch=" tag before and will know if/how to apply it. But using it, matches to what the installer does: https://github.com/docker/docker-install/blob/master/install.sh#L379

Else I agree that the notes take too much space, so removing only the note about it should be fine as well. I added it mainly to be consistent with the note about the lsb_release command substitution note.

An alternative would be collapsible notes, if you have the pymdownx.details Markdown extension enabled?

• https://facelessuser.github.io/pymdown-extensions/extensions/details/
• Like here in our MkDocs-powered docs: https://dietpi.com/docs/software/

Could be achieved with <details><summary> HTML5 tags manually as well.

If we do think it's useful, perhaps we should move it inside each tab,

But this doesn't "solve" the issue that the notes are much larger than the command block and adds the inconsistency that dpkg --print-architecture is explained inside the tab, while lsb_release is explained outside, even that for both basically the same is true: It is fine in 99% of cases and in the remaining rare cases, admin must have known already about their limitation on that system 😉.

@thaJeztah
To push this a bit:

• I played with the details tag and it would require some more CSS to make it nice, which is out of scope for this PR.
• Moving the note as text into the tab doubles the code and does not solve the issue that text blocks are larger than the command block. If only the blue note style is to prominent, then we could also un-note the two notes and leave them where they are.
• I personally do not like to use two command substitutions but explain only one of them. Either we explain both or none, would be my very personal preference 😄. But I follow your preference, of course!

I finally suggest to remove dpkg --print-architecture completely, the note and also the code.

It is a no-op, as DPkg anyway installs packages for the major architecture (output of dpkg --print-architecture), even if the version was lower. Only if a package is not available for the major architecture, it looks into foreign architecture lists. Declaring the architecture explicitly would break that automatic behaviour, even that it is most likely wanted: Hypothetically a new ARMv9 architecture may be created that is backwards-compatible to ARMv8=arm64 and the Docker repo does not yet ship binaries for it. If arm64 is added as foreign architecture, without declaring the architecture in the list file, DPkg would automatically install the arm64 package that runs on that system. If arm64 were incompatible with that hypothetical ARMv9 CPU, then the admin would not add arm64 as foreign architecture, so that APT/DPkg would error out with a meaningful error message.