But,Thomas, if you want to redo so it is smaller that's okay too. On Tue, Jun 16, 2020 at 12:30 PM Rocky Bernstein <ro...@gnu.org> wrote:
> Ok. I let's just go with the existing image. > > On Tue, Jun 16, 2020 at 12:04 PM Pete Batard <pbat...@gmail.com> wrote: > >> On 2020.06.16 15:48, Thomas Schmitt wrote: >> > But if it is for size, then the existing >> > test/data/deep-directory.iso >> > is too large by the traditional padding of 150 * 2048 bytes (which is >> > needed only if the ISO gets onto a CD by write type TAO from which it >> > shall be read by the Linux kernel's block device driver). >> > >> > So Pete could re-create it by mkisofs using option -no-pad. >> > It would then shrink from 397,312 bytes to 90,112. >> > >> > Alternatively one could simply compress the ISO in git and tarball and >> > let the test program decompress it: >> > >> > $ gzip -9 <test/data/deep-directory.iso | wc -c >> > 2420 >> >> Three things about this: >> >> 1. git does compress content behind the scenes pretty effectively, so >> the only size issue here is with users having to ensure that they have a >> "whooping" 300 KB extra free to host their repo... which, in 2020, I >> hope is not something we feel we have to lose sleep over. >> >> 2. I've been using Folder2Iso to create that image (because it was the >> most convenient), which calls mkisofs behind the scenes but does not >> provide options to alter settings. >> >> 3. I am estimating that the time I would spend recreating the ISO to >> save those 300 KB which aren't actually going to cost us repository >> space is simply not worth the effort at this stage. There's just nothing >> to be gained from saving a couple hundred KB (again, not in bandwidth, >> thanks to git compression) for people who clone our repo. As such I am >> not planning to update the proposed test ISO, as I'd rather use the time >> I'm going to save not doing that on other things (such as ensuring one >> last time that what I am going to merge is not going to create issues). >> >> I hope that it's okay. And yes, I do understand that, ideally, we'd like >> to provide the smallest test ISOs or be as academical as we possibly >> can, but I'd rather invest time, which is always in short supply, on >> elements that will actually improve people's lives, and this just isn't >> one of them... >> >> Regards, >> >> /Pete >> >>
