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
We do what create_gconf is trying to achieve in get_config_files(). What's
more, the files in crete_gconf() end up in the root directory where
nothing can possibly use them because the root user's home is now /root.
This allows for installation of package's language packs without needing to
list them explicitly in the <foo>-support comps groups. Those groups (and
the corresponding code in yuminstall.py) are still needed at least in the
short term, due to fonts, input methods, and some internal architecture
issues in the plugin.
