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
