#962 PR merged: Improve debian packaging

Labels: enhancement, fixed / solved / done

carragom opened issue at 2016-08-12 12:52:


This should solve #828 and #696. In this pull priority is given to the xorrisofs binary over the other binaries (mkisofs and genisoimage).

Let me know what you guys think.

jsmeix commented at 2016-08-12 13:48:

I cannot comment on packaging/debian/control
because I know nothing at all about Debian packaging
which means packaging/debian/control is o.k. for me

Regarding usr/share/rear/conf/default.conf
please add an explanatory comment there
about the priority - i.e. that xorrisofs is used
with highest priority (if exists), then mkisofs
and finally genisoimage.

this is a change in default behaviour,
see usr/share/rear/conf/default.conf
now xorrisofs is used with highest priority when it exists,
before mkisofs was used with highest priority.
Is this o.k.?

jsmeix commented at 2016-08-12 13:50:

... and preferably I would like to be informed in the
comment in usr/share/rear/conf/default.conf
why the priority is set this way, cf.
"Code should be easy to understand" in

carragom commented at 2016-08-13 12:49:


I have added the required comment, check it out and let know if it's good.


jsmeix commented at 2016-08-15 10:04:

I tested it on my SLES12-SP2-beta5 test system.
It works for me (both "rear mkbackup" and "rear recover")
and my "rear mkbackup" log shows:

++ pushd /tmp/rear.aX4QCYG3LkqNb98/tmp/isofs
+++ basename /usr/bin/xorrisofs
++ test ebiso = xorrisofs
++ /usr/bin/xorrisofs -v -o /root/rear/var/lib/rear/output/rear-g62.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -R -J -volid RELAXRECOVER -v -iso-level 3 .
xorriso 1.3.4 : RockRidge filesystem manipulator, libburnia project.
Drive current: -outdev 'stdio:/root/rear/var/lib/rear/output/rear-g62.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 13.1g free
Added to ISO image: directory '/'='/tmp/rear.aX4QCYG3LkqNb98/tmp/isofs'
xorriso : UPDATE : 14 files added in 1 seconds
xorriso : UPDATE : 14 files added in 1 seconds
xorriso : UPDATE :  10.68% done
xorriso : UPDATE :  10.68% done
xorriso : UPDATE :  64.07% done
ISO image produced: 76719 sectors
Written to medium : 76719 sectors at LBA 0
Writing to 'stdio:/root/rear/var/lib/rear/output/rear-g62.iso' completed successfully.
++ StopIfError 'Could not create ISO image (with /usr/bin/xorrisofs)'
++ ((  0 != 0  ))
++ popd

If the new default does not work on whatever Linux distribution(s)
there is the easy solution that the user must simply specify his
actually working ISO_MKISOFS_BIN in his /etc/rear/local.conf.

The only possible drawback with the new default
that I recognized up to now is the ISO image size:

On my SLES12-SP2-beta5 test system I get
with ISO_MKISOFS_BIN="$( type -p mkisofs )"
and ISO_MKISOFS_BIN="$( type -p genisoimage )"
an ISO image with about 90 M size
but with ISO_MKISOFS_BIN="$( type -p xorrisofs )"
I get an ISO image with about 150 M size.

I.e. about 50% bigger ISO image size with xorrisofs.

Not that 50 M would matter much for one
or a few ISO images for personal usage
but in enterprise environments with hundreds or
thosands of servers megabytes difference for each
sum up to gigabytes overall difference, cf.
https://github.com/rear/rear/issues/841 and

But also when ISO image size matters there is the same
easy solution as above that the user can simply specify his
best working ISO_MKISOFS_BIN in his /etc/rear/local.conf.

Bottom line from my current point of view:
I would merge it.


jsmeix commented at 2016-08-15 10:06:

have a look at this one, it should fix your https://github.com/rear/rear/issues/696

have a look at this one, it should fix your https://github.com/rear/rear/issues/828

erkannt commented at 2016-08-15 12:47:

Would love to but I switched my server to BIOS, sorry.

[Export of Github issue for rear/rear.]