[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1124082: debian-installer: please rename mini.iso to e.g.debian-13.2.0-amd64-mini.iso



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

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/

> 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.

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?

> 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.

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

> 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?

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,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature


Reply to: