#962 PR merged
: Improve debian packaging¶
Labels: enhancement
, fixed / solved / done
carragom opened issue at 2016-08-12 12:52:¶
@jsmeix
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.
Cheers.
jsmeix commented at 2016-08-12 13:48:¶
@carragom
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.
@gdha
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
https://github.com/rear/rear/wiki/Coding-Style
carragom commented at 2016-08-13 12:49:¶
@jsmeix
I have added the required comment, check it out and let know if it's good.
Cheers.
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
https://github.com/rear/rear/issues/810#issuecomment-205783287
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.
@gdha
objections?
jsmeix commented at 2016-08-15 10:06:¶
@aussendorf
have a look at this one, it should fix your
https://github.com/rear/rear/issues/696
@erkannt
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.]