Simplify adopting `chisel` distroless base images (`static` / `base` / `cc`)

**Summary:**

Multiple Canonical/Ubuntu resources refer to minimal image sizes while comparing to Google distroless image size.
- There are no equivalent images presently published for use?
- Proper recreation requires more effort and technical confidence from the user. More verbose and fragile than some published rocks?
- No package/slice that could simplify creation? (_along with an official `chisel` image published_)

Are these intentionally not published for some reason? Or are there plans to simplify producing such?

---

In [this Jan 2023 guide](https://ubuntu.com/blog/craft-custom-chiselled-ubuntu-distroless) (_prior to the Nov 2023 General Availability announcement_), the first step is to build `chisel`. The 2nd step was then to use `chisel` to create a minimal image like the Google distroless ones offer.

Image from guide (click to view)

> 

This page shows some comparisions to promote `chisel`, comparing to published rocks that are available on DockerHub for services and language runtimes, but this last one about a minimal equivalent image suitable for Go and Rust projects is nowhere to be found:

Images from online resources

> https://ubuntu.com/containers/chiselled
>
> 

> https://ubuntu.com/blog/combining-distroless-and-ubuntu-chiselled-containers
>
> 

> https://canonical.com/blog/chiselled-ubuntu-ga
>
> 

---

The benefits of that minimal base are shown above, and it's useful for projects that just need to have basic deps like glibc with `/etc/passwd` + `/etc/group`, and `ca-certificates`, possibly TZ data.

I don't recall from the various resources I came across, any explanation for why chiseled images are produced for some services and language runtimes, but not these minimal glibc / distroless base image referenced above?

The project README does seem to [suggest getting `chisel` and demonstrating an example](https://github.com/canonical/chisel?tab=readme-ov-file#example-command) which is simple enough. But I'd assume that's not too different for the published images? (_like this using this [Python3.12 slice](https://github.com/canonical/chisel-releases/blob/ubuntu-24.04/slices/python3.12.yaml)_)

## Recreating the Python rock with `chisel`

I think the Python image might look something like this?:

```console
# `chisel` lacks the ability to create the `--root` dir for you when it doesn't exist:
mkdir /rootfs

# Produces 40MB output:
# - `ubuntu/python:3.12-24.04_stable` image appears to roughly match contents of these slices, but is 48MB in size.
# - Missing `pebble` binary (8MB) and the `/etc/{passwd,group,localtime}` files.
chisel cut --release ubuntu-24.04 --root /rootfs \
python3.12_standard \
tzdata_zoneinfo \
ca-certificates_data-with-certs \
openssl_config \
base-files_base
```

**EDIT:** I found the actual [`rockcraft.yaml` used to build `ubuntu/python:3.12-24.04_stable`](https://github.com/canonical/chiselled-python/blob/main/python3.12/rockcraft.yaml) (_it'd be nice if the DockerHub image README referenced that btw! I wasn't sure where or what the build source was for a while until I learned more about "rocks"_). It seems I was reasonably close at guessing it's internals 😎 (_this will be easier to derive once that manifest feature arrives I assume_)

- While I didn't explicitly provide `lib6_libs` or `libgcc_s-1` like the `rockcraft.yaml` has explicitly, those are [brought in from the dependency chain](https://github.com/canonical/chisel-releases/blob/d919a1b48c5537b662a7257f3feb963d13323a57/slices/libpython3.12-stdlib.yaml#L17-L24), similar to how the `rockcraft.yaml` brings in [`tzdata_zoneinfo` from an implicit python dep](https://github.com/canonical/chisel-releases/blob/d919a1b48c5537b662a7257f3feb963d13323a57/slices/libpython3.12-stdlib.yaml#L131).
- Although the [`rockcraft.yaml` was last modified Aug 7](https://github.com/canonical/chiselled-python/blob/e0943bf2923ef50c9117ac58cd02a86146ece1fb/python3.12/rockcraft.yaml#L28) where it's slice for `ca-certificates_data` was [reverted upstream on Aug 12](https://github.com/canonical/chisel-releases/pull/310) to what was `ca-certificates_data-with-certs`. Thus building that rock at present will not match the current published image, and that's why I assumed `ca-certificates_data-with-certs` based on the content (_no clue if the Python rock image actually requires the extra data from that slice_).