If an image explicitly actively supports/encourages Alpine variant usage (like Rust, for example?), it should have an override for this file to make the level of support more clear (see `golang/variant-alpine.md` and `openjdk/variant-alpine.md` for examples of clarifying the level of Alpine support within those projects).
> ## `ruby:<version>`
>
> This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
>
> Some of these tags may have names like buster or stretch in them. These are the suite code names for releases of [Debian](https://wiki.debian.org/DebianReleases) and indicate which release the image is based on. If your image needs to install any additional packages beyond what comes with the image, you'll likely want to specify one of these explicitly to minimize breakage when there are new releases of Debian.
>
> This tag is based off of [`buildpack-deps`](https://hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of Docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
This really hasn't been horribly relevant for a long time (it was more relevant back when Docker was more frequently making breaking changes to things like image format and those have all been very calm for years now).
For context, this was added initially because the previous rendering of Markdown on the Hub was such that code in a link would render without underline and barely noticeable blue color (and no hover behavior either besides the normal cursor change), so it wasn't clear it was even a link without additional non-code text. Now that that has been corrected/adjusted, I think it's totally reasonable to remove those (since they're included in the link already).
For reference/comparison, this takes the `open-liberty` readme from ~39k characters down to ~33k characters.
This also changes the `buildpack-deps` detection so that it only triggers the "this image is large with lots of packages" description if some tag of the image being described is `FROM buildpack-deps` (and _not_ simply `-curl` or `-scm` variants), which adjusts `golang`, `haxe`, `influxdb`, `kapacitor`, `openjdk`, and `telegraf` to correctly have the shorter non-`buildpack-deps`-referencing description.
This uses the combination of us pushing to a namespace + `BASHBREW_ARCH` being set to determine whether we're pushing to an arch-specific page and should thus appropriately filter all content to the current architecture.
This should make it much faster to find the right place to file issues, get help, find out whether upstream maintains an image, etc.
I've done my best to represent each `REPO/maintainer.md` file appropriately, but I might have missed some (or there might be something else a maintainer prefers be listed there, either more or less descriptive, for example), which would be welcome contributions following this change.
Tianon Gravi