Hi, i wrote: > > https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/test/merge_debian_isos
Steve McIntyre wrote: > That might be a useful thing to include in a package. What do you think? Best would be if debian-cd would take it, so that it can be adapted when the repository format in the ISOs gets changed. It could be renamed to e.g. "debian-cd-merge-isos" and become a separate "binary" package from the debian-cd source package. I would of course be willing to help with maintaining it. But first it needs more testing, especially whether the resulting ISO lacks anything that an ISO-1 from debian-cd with the same packages has. Zhang Boyang posted a comparison in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011343#115 https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1011343;filename=diff.details.txt;msg=115 about which i ponder: - Shall the script create a new /.disk/mkisofs ? The used xorriso run has few similarity with a xorriso run from debian-cd. The pool content and package lists have no influence on the xorriso run of debian-cd. So it might be better to stay with the original. - There are some /firmware files missing in the merged ISO. Like /firmware/arm-trusted-firmware-tools_2.4+dfsg-2_amd64.deb ... /firmware/gnome-firmware_3.36.0-1_amd64.deb They are in the pool of DLBD-1. But how did they get into /firmware of Zhang Boyang's CUSTOM(all-in-one) ? (Or: Why aren't they in /firmware of DLBD-1 ?) I hope that the script is sufficiently stable against bad arguments and bad combinations of ISOs. At least i inserted a lot of error messages and took care to trigger each of them. Nevertheless, it should be tested independently of me whether it can be tricked into destroying existing data on disk or leaving temporary files on disk. Have a nice day :) Thomas