Hi, some technical nitpicking.
Andrew M.A. Cater wrote: > Also, keeping large files around on disk for a long > time - there's some likelihood of data corruption. The .jigdo and .template files of the DLBD ISOs are together smaller than a netinst CD ISO. (Less than 90 MiB, see https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dlbd/ ) Building an ALL-IN-ONE would cost the computing time of another ISO set (*) and 50 % percent more virtual memory than building DLBD1 (**). I assume that the main workload with an additional set of jigdoized ISOs is the need to once more shovel 75 GB of package files through libisofs and libjte so that they can create .template and .jigdo files. The ISOs themselves get directly piped into /dev/null, i guess. > I'd hate a couple of > bit flips three quarters of the way through a 6TB file, say, to mean that > the whole thing isuseless. The vast majority of data is stored as packages on the worldwide mirrors. I'd expect some quality of filesystem and backup which keeps damage confined to a few packages. There are a lot of outdated mirrors around where one could dig for those which really got lost from all active mirrors. I remember the hunt for a package which once was overwritten by a newer version with the same .deb file name. It was needed for building an old ISO from .jigdo which was created when the new version did not yet exist. But even without finding the older version, the emerging ISO would have been usable for all purposes which don't touch that one rogue package. ------------------------------------------------------------------------ Every time this wish pops up, i begin to ponder what is theoretically needed to unite several pool trees from multiple ISOs into one, so that it works like an official ALL-IN-ONE ISO. Putting all files together and making the ISO bootable would be no problem. But what does a neat pool have to offer as merged lists or other meta-data so that it properly announces its content ? ------------------------------------------------------------------------ Footnotes: (*) Computing time: Maybe it needs a bit more than DLBD[12] together, because the insertion algorithm of libisofs has a quadratic aspect in its personality. But the branchy pool tree helps a lot to keep this problem under the cover. (**) Virtual memory consumption: The memory consumption of libisofs mainly depends on the number of files and the length of their names. *11.3.0-amd64-DLBD-[12].jigdo together list ~ 59,000 files with ~ 2.2 MiB of basename length. My daily BD backups have ~ 70,000 files with ~ 1.4 MiB of basename length and do not demand gigabytes of RAM. Have a nice day :) Thomas
