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

2025-12-28 Thread Cyril Brulebois 
Martin-Éric Racine  (2025-12-28):
> su 28.12.2025 klo 15.15 Cyril Brulebois ([email protected]) kirjoitti:
> > 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?
> 
> 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?

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

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

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


Cheers,
-- 
Cyril Brulebois ([email protected])
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

2025-12-28 Thread Martin-Éric Racine 
su 28.12.2025 klo 15.15 Cyril Brulebois ([email protected]) kirjoitti:
>
> Martin-Éric Racine  (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.
[...]
> 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?

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?

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

Agreed.

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

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

2025-12-28 Thread Cyril Brulebois 
Martin-Éric Racine  (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 ([email protected])
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

2025-12-28 Thread Holger Levsen 
On Sun, Dec 28, 2025 at 01:55:30PM +0100, Cyril Brulebois wrote:
> > if they are not useful (or even worse, out of sync, or some such), rm them.
> > if they are useful, name them properly.
> There's no “proper name” in the first place (see details in the parts of
> my mail you didn't reply to).

then I suggested to remove them. (see first line of the quoted part of my mail 
:)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Ich bin so alt, ich hab im Kindergarten noch Aschenbecher getöpfert.
(@joanalistin)


signature.asc
Description: PGP signature

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

2025-12-28 Thread Cyril Brulebois 
Holger Levsen  (2025-12-28):
> On Sat, Dec 27, 2025 at 10:57:26PM +0100, Cyril Brulebois wrote:
> > 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…
> 
> 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.

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


Cheers,
-- 
Cyril Brulebois ([email protected])
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

2025-12-28 Thread Holger Levsen 
On Sat, Dec 27, 2025 at 10:57:26PM +0100, Cyril Brulebois wrote:
> 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…

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.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

I don't want to see your smile.
I want to see your intelligence, compassion, integrity, and consideration.
(@1goodtern)


signature.asc
Description: PGP signature

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

2025-12-28 Thread Martin-Éric Racine 
la 27.12.2025 klo 23.57 Cyril Brulebois ([email protected]) kirjoitti:
>
> Control: tag -1 wontfix
>
> Martin-Éric Racine  (2025-12-27):
> > 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
>
> 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…

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.

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

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.

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

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

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

2025-12-27 Thread Debian Bug Tracking System 
Processing control commands:

> tag -1 wontfix
Bug #1124082 [debian-installer] debian-installer: please rename mini.iso to 
e.g.debian-13.2.0-amd64-mini.iso
Added tag(s) wontfix.

-- 
1124082: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124082
Debian Bug Tracking System
Contact [email protected] with problems

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

2025-12-27 Thread Cyril Brulebois 
Control: tag -1 wontfix

Martin-Éric Racine  (2025-12-27):
> 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

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…

> 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

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,
-- 
Cyril Brulebois ([email protected])
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

2025-12-27 Thread Martin-Éric Racine 
Package: debian-installer
Severity: wishlist
X-Debbugs-Cc: [email protected], [email protected]
User: [email protected]
Usertags: amd64

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

-- System Information:
Debian Release: 13.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.57+deb13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled