Any decisions about arch-specific stuff should happen in the Lorax class
or the arch-specific templates/code. Move that logic up to Lorax.run()
and remove installtree.basearch.
getdata(cmd) will return a generator that yields every token on every
line that starts with the token "cmd". getdata(cmd, mode="lines") will
yield a list for each line rather than every individual token.
this simplifies some things in __init__.py.
arch has three attributes: .buildarch, .basearch, and .libdir
product has six: .name, .version, .release, .variant, .bugurl, and
is_beta
This makes it easier to pass this data into functions/templates.
TreeBuilder uses templates full of commands (like ramdisk.ltmpl) to
create the output tree and boot images. There are 4 arch-specific
templates, plus a bonus EFI template which can handle EFI image creation
for any arch that implements EFI.
This adds the new "mkefiboot" cmd, which creates an efiboot img in the
magical way that EFI requires. There doesn't seem to be a good tool for
this (unlike the existing tools for all the other weirdo boot image
types) so it was necessary to create one.
This contains simple functions for creating disk images:
mkcpio, mksquashfs, mkdosimg, mkext4img, mkbtrfsimg
And the helper functions they use:
truncate, loop_{attach,detach}, dm_{attach,detach},
mount/umount, estimate_size, roundup, cpio_copytree
This adds the remove() function, which works a lot like rm -rf - if you
remove() a file, it uses os.unlink, and if you remove() a directory it
uses shutils.rmtree().
If you're doing e.g. an i386 build an an x86_64 build at the same time,
you wind up deadlocking the dmsetup processes in sys_semtimedop()
because they have the same name between the two codepaths. This is
probbaly a dmsetup bug, but even if it weren't, you'd still have two
composes trying to use the same dm devices, and that's bad. Instead,
stick the pid in the names.
We're already using find and cpio subprocesses, so using
one more subprocess is not a problem. With this approach
we can pipe cpio to the xz/gzip command, which should
help with the memory issues.
A python lib we use (python-value_key) depends on this. If it fails to
import the module we see weird problems importing python modules backed up
by .so libraries, for instance:
ImportError: /lib64/libcryptsetup.so.1: undefined symbol: uuid_generate
Related: rhbz#684742
