Optional container images for building and running LTFS

Inizia esaminando il branch feature/docker, la relativa directory docker/, il workflow, .dockerignore e il README di primo livello, quindi analizza le correzioni menzionate in ltfs_ordered_copy e configure.ac. Conferma l’ambito concordato dell’immagine, il budget CI, gli autotest, i marcatori di revisione e la documentazione prima di considerare concluso il lavoro.

Is your feature request related to a problem? Please describe.

Hi — thanks for LTFS. I deploy it on hosts with tape drives attached, and what I
wanted was to build it once and then simply run it: hand the same image to another
machine, or to someone else, and have it work without them setting up a toolchain at
all. That is really what a container buys here — not building for many distributions,
but not having to build a second time.

Describe the solution you'd like

I have built a containerized Autotools environment and would like to ask whether you
would be interested in it upstream. It adds a docker/ directory, one workflow, a
.dockerignore, and a short section in the top-level README — no deletions, and no
existing workflow, build file or source behaviour changes. linux/amd64 only.

Each distribution produces two images by role:

• In-support (both roles): Ubuntu 26.04 / 24.04 / 22.04, Debian 13 / 12,
  Rocky Linux 10 / 9 / 8.
• EOL (runtime only): Debian 11 / 10 / 9, Ubuntu 20.04 / 18.04 / 16.04,
  CentOS 7, Fedora 28.

24 images in total. LTFS builds and works on all of them, EOL included. The EOL
ones build from frozen distribution archives, and each enforces a glibc ceiling at
build time (2.17 for CentOS 7 up to 2.31 for Debian 11) so the binaries really do run
on those old hosts.

Those EOL images are neither published nor built in CI: their base OS gets no
security updates, and their frozen archives do occasionally move or disappear — which
is something the person building one needs to see, not something a weekly red run
would help with. Their definitions are still linted, so a broken one cannot reach
them.

Since nothing automated watches them, they are verified by hand and the commit is
recorded. All eight built and passed their own self-test at
3a8ac9bfe5bec69112f214b1b10fcc1815cd12f2, and each image carries that revision in
/usr/local/share/ltfs-autotools/build-revision, so any image can say for itself
which source it came from.

Every image validates itself as it builds. Building dev compiles the source in a
throwaway stage, and only a pass marker naming the revision is carried forward — the
source tree never lands in the image. Building runtime runs a smoke test and formats
a virtual tape through the file backend, and the build fails if either does.

I also tested this on real hardware, since a green file-backend build says little
about the sg path. On an IBM ULTRIUM-HH8 (LTO-8) I ran the runtime image end to end:
enumerate the drive over sg, mkltfs a real cartridge, mount via FUSE, write 1 MiB,
unmount cleanly, remount in a fresh container, and read it back byte-identical.
ltfsck reports the volume consistent.

Describe alternatives you've considered

Keeping it in my own fork, which works fine — I am offering it because the
per-distribution build problem seems common. I am also happy with a smaller scope
(fewer distributions, or runtime only) if you prefer.

Additional context

• Two small fixes are needed for the images to build and I would include them:
  ltfs_ordered_copy uses an f-string (breaks on the Python 3.5 in older bases), and
  configure.ac finds dlopen only because net-snmp pulls in -ldl. Happy to send
  them separately.
• Nothing needs to be published — the workflow validates without pushing anywhere.
• It does cost Actions minutes, and I would rather you set the budget than have me
  guess: as written it fans out one job per in-support distribution on every push and
  pull request, plus a weekly run to catch base images drifting. EOL images are not
  built at all. Narrowing this further — pull requests only, or weekly only — is a
  two-line change, so please say what suits you.
• Distribution differences live as data in one Bake file, so adding a release is a few
  lines, not a new Dockerfile.
• Found while testing this but not caused by it, and I will report it separately:
  ltfs -a segfaults when LANG names a locale the system has not generated —
  libfuse's iconv module calls strdup(setlocale(LC_CTYPE, "")) unguarded while
  printing module help, and ltfs -a reaches it through fuse_main() in
  src/main.c. Nothing about it is container-specific — generating the locale makes
  it go away and removing it brings it back. ltfs -h is unaffected.

The work is on a feature/docker branch and I can open a PR against release/v2.4.9.0
whenever suits you. Thanks for taking a look.