Re: Final CDs being written for Stretch - 9.13 release - prior to LTS
Hi,
(The mail headers indicate that the OP, Andrew Cater, is subscribed to
debian-cd but not to debian-user. So replies to debian-user only might
not get to his attention.)
Stefan Monnier wrote:
> An alternative is to have "virtual ISO images", i.e. images which are
> constructed on the fly (presumably by jigdo) on the web-server side.
Assuming that a complete set of ISOs for whatever medium occupies
at most 100 GB, it seems better to have the images ready rather than to
assemble them on demand, even if the mirror latency and bandwidth are
no problem.
This would spare the nightmare of managing the life cycle of temporary ISOs
on the server. I assume that all images would fit on a single modern HDD.
But the reason for letting the user perform jigdo download is that the network
load vanishes in the normal traffic of the package servers. If download gets
interrupted, one just has to start it again to get the remaining work
completed.
These adavantages for Debian can hardly be uphold by a jigdo assembling
server on Debian side.
> I'm not sure why the discussion is always around DVD images.
That's mainly about the image size factor of a 4+ GB DVD.
There is one size factor that is not defined by optical media sizes
https://cdimage.debian.org/debian-cd/current/amd64/jigdo-16G/
> Would you be equally happy with an image only for a USB flash drive, or
> is it important for it to be an image for optical media?
The ISOs work from optical media and from hard-disk-like media.
The latter class includes USB sticks and memory cards.
The production of jigdo files is a linear effort only if the producer
knows where the filesystem stores file content data. This knowledge is in
the ISO 9660 producers genisoimage and xorriso. For other filesystems
the matching jigdo producer software is not available yet.
Further the filesystem must store the content of each Debian package as one
consequtive sequence of bytes. Fragmentation is not supported by jigdo.
For some reason even fancy container systems use ISOs for deployment.
https://nanikjava.github.io/post/insideminikubeiso/
The example i found is BIOS-only and (virtual) CD-only
https://storage.googleapis.com/minikube/iso/minikube-v1.0.0.iso
Maybe it's because the user would need to start an ISO 9660 manipulating
program in order to alter them. This hardly happens by mistake.
Have a nice day :)
Thomas
Reply to: