static: Use bin/share/doc layout in archives

[vvoland]

Restructure the static archive staging directories to follow the
FHS-style bin/share/doc hierarchy.

• bin/
• share/doc//LICENSE
• share/doc//README.md

This allows users to extract directly into a prefix directory with no
extra steps:

tar -C /usr/local -xzf docker-buildx-linux-amd64.tgz

Previously, archives contained a single top-level named subdirectory
(e.g. docker-buildx/), so users had to either cd into it after
extraction or use --strip-components=1.

[thaJeztah]

I'm a bit hesitant on having no directory at all; specifically if the archive contains multiple; it makes it really easy to accidentally unzip/untar and end up with the content sprayed across your current directory.

requiring users to cd into it after extraction.

It's not strictly needed; currently you can opt-in to skipping the directory, e.g. with --strip-components=1 (which would extract everything skipping the directory).

Not sure what the exact equivalent is for Zip; looks like unzip -j archive.zip would skip all directory structure.

One thing we CAN consider (but mainly for Linux / macOS) is to use the same approach as containerd;

tar -tzf containerd-2.3.2-linux-amd64.tar.gz
bin/
bin/containerd
bin/containerd-shim-runc-v2
bin/ctr
bin/containerd-stress

tar -tzf docker-29.6.1.tgz
docker/
docker/containerd
docker/dockerd
docker/docker-init
docker/runc
docker/docker-proxy
docker/docker
docker/ctr
docker/containerd-shim-runc-v2

Using bin/ (and similar paths) allows extracting the content directly to a prefix path;

tar -C /usr/local -xzf containerd-2.3.2-linux-amd64.tar.gz

tree /usr/local/
/usr/local/
├── bin
│   ├── containerd
│   ├── containerd-shim-runc-v2
│   ├── containerd-stress
│   └── ctr
├── lib
└── share

3 directories, 4 files

That would also allow bundling other things (/usr/local/lib, ...)

[vvoland]

Ah, the bin/lib makes sense indeed. How about LICENSE files?

[thaJeztah]

Ah, the bin/lib makes sense indeed. How about LICENSE files?

Yeah, I think that would be something like;

• documentation / licenses: /usr/local/share/doc/<package name>/LICENSE (and NOTICE and README.md or what else)
• man-pages; /usr/local/share/man/

Basically, I think those paths would be the same as we use for our deb and rpm

[thaJeztah]

LGTM

once we completed these changes, we should probably also look at updating instructions; one thing we didn't consider / document so far is the alternative to use /opt; https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html

Basically, would use the same structure, but prefixed by the package name, e.g.;

/opt/docker-29.6.1/
├── bin/
├── share/
│   ├── doc/
│   │   └── docker/
│   └── man/
└── ...

Users can then add that to their PATH (or symlink) to update a version