While d-i images mostly follow a consistent naming scheme, there are two notable exceptions: the mini netboot ISO and hd-media:

mini.iso
boot.img.gz

It would be desirable for these to follow the naming convention used for other images:

debian-13.2.0-amd64-mini.iso
debian-13.2.0-amd64-boot.img.gz


Cheers!
Martin-Éric

Martin-Éric Racine <martin-eric.racine@iki.fi> (2025-12-27):

Those are artifacts of the src:debian-installer build, and while
they're available on mirrors, those aren't really “d-i images”.

I see how versioning them might make it easier for (presumably expert)
users to keep track of their downloads, but I don't think we would want
to give those files a more “official-looking” status…

Additionally they aren't produced in lockstep with debian-cd, who
consumes the state of a mirror at a given point and massages it into
images based on its configuration.

We couldn't guarantee a 1:1 mapping between what happens when
src:debian-installer is built and what happens later when debian-cd
runs: maybe the latest d-i artifacts will need to be replaced by
something else, maybe the version numbers won't match for some reason
(e.g. what happens if we need to respin images, leading to x.y.1
versions?), etc.

Tagging as wontfix for now, happy to get more feedback from others,
but that looks like -done@ territory to me.


Cheers,

my 2 cents:

if they are not useful (or even worse, out of sync, or some such), rm them.
if they are useful, name them properly.

la 27.12.2025 klo 23.57 Cyril Brulebois (kibi@debian.org) kirjoitti:

It indeed is about making it easier to keep track of downloads.
Currently, I have to download the mini ISO, mount it, then cat
.disk/info to know what to rename it to. It also means that I have to
do this for every architecture I download, instead of just downloading
a bunch of files and letting the filename tell me which distribution
and architecture is the target.

Not produced in lockstep might indeed be an issue. Still, I don't see
why the scripts used to generate these couldn't include the version
the image was built from in the filename.

Personally, I prefer using mini-ISO over the full netinst-ISO because
it's a much smaller file to flash. It also ensures that whatever is
used for the install or rescue is the latest version found on the
Debian repository. With the full netinst image, we first use as many
deb/udeb as we can from the ISO, then later upgrade to what is on the
repository, which feels like an unnecessary step. IMHO, the full
netinst-ISO made sense back in the days when a minimal installation
without network access was a common case. Nowadays, installing without
any network access is rather unusual.

Noted.

This is a mere wishlist bug anyhow, because descriptive filenames
generally are a good idea since they simplify people's life. Team d-i
is of course welcome to consider this as non-essential for files that
fall outside the scope of cdimage.d.o mirrors, which is the case for
mini-ISO and HD-media.

Alternately, merely using filenames without the minor release digit
would already be a significant improvement:

debian-13-amd64-mini.iso
debian-13-amd64-boot.img.gz

Even this minimal implementation would already be better than the
current situation. Would you consider this option as a doable
compromise?

Cheers!
Martin-Éric

Holger Levsen <holger@layer-acht.org> (2025-12-28):

There's no “proper name” in the first place (see details in the parts of
my mail you didn't reply to).


Cheers,

Martin-Éric Racine <martin-eric.racine@iki.fi> (2025-12-28):

Let's see what's inside those files:

    Debian GNU/Linux 12 (bookworm) amd64 - netboot mini.iso 20230607+deb12u12

As you can see, that's linked to a *debian-installer* version, for which
there's no 1:1 mapping regarding an actual release this might or might
not be included into.

On a filesystem, it's pretty clear that the “current” directory is
actually a symlink to 20230607+deb12u12 (same version), so depending on
what URL you follow, you might or might know that. A quick look around
on various mirrors suggest they serve current/ as an actual directory
with a listing, rather than redirect to 20230607+deb12uN/

Well, if we were to do that, where do we stop? Do we rename all kernels,
initramfes? What about when they're the same in different directories
(see gtk, SD-card-images, depthcharge, etc.) Do we flatten everything to
have unique filenames? Plus we lose the ability to point tools at just
“whatever is current”.

A minimal change that would make it possible for you to automate your
downloads would be echo-ing the version in a top-level file, alongside
MANIFEST*, *SUMS, etc. Something like VERSIONS containing just
20230607+deb12u12. Would that help?

I know the pros and cons, and whether mini.iso is useful wasn't the
point.

This would still break automation, and that wouldn't be reasonable
anyway. If we had that at the time trixie was released, we would have
that in trixie, forky, and sid directories right now. What happens when
a forky release is getting prepared? We'd get debian-14-* names in sid
directories…


Cheers,

su 28.12.2025 klo 15.15 Cyril Brulebois (kibi@debian.org) kirjoitti:
[...]

Possibly. Would that be implemented at the Debian mirror generation
level, or are you implying that I should just come up with my own
script?

Another question: Would including mini-ISO into the regular batch
release scripting for cdimage (and thus adding mini-ISO to cdimage
mirrors) be entirely out of the question? Then it would always be in
sync and following the naming convention would come as a byproduct.

Martin-Éric

Martin-Éric Racine <martin-eric.racine@iki.fi> (2025-12-28):

What I had in mind was adding some kind of `echo $VERSION > VERSION` in
the src:debian-installer build system, so that the VERSION file would be
shipped alongside the rest, then included into the archive, allowing for
easier introspection than looking into .disk/* after loop-mounting
stuff. (The archive tooling merely unpacks a specific tarball into
place, there's no specific “Debian mirror generation” magic.)

Paging debian-cd@, that's their realm. If they're happy with it, they
can steal this bug report.


Cheers,