meta-translator =============== Overview --- meta-translator extends the oe-core archiver and package_rpm classes to produce source RPM (src.rpm) packages with build commands, so that they can be rebuild natively without the need for bitbake (i.e. on the target, or in a build system such as OBS). Usage --- To use the archiver, the following variables need to be set: # Enable the archiver, or src.rpm generation is not possible INHERIT += "archiver" # Archive the original sources, not patched or configured ARCHIVER_MODE[src] = "original" # Switch archiver mode to SRPM ARCHIVER_MODE[srpm] = "1" # Do not allow empty packages to be built (.rpm or .src.rpm) # This will prevent bitbake from making a bootable image however, due to # missing packagegroup* meta packages (which are empty) SRPM_ALLOW_EMPTY = "1" To generate the source RPMs for a recipe and all of the dependencies, use the "srpms" task: $ bitbake core-image-sato -c srpms To generate the source RPMs for a specific recipe and not the dependencies, use the "deploy_archives" task: $ bitbake m4 -c deploy_archives (the translator task is a simple wrapper around deploy_archives that adds dependency recursion) The final .src.rpm files will be found in tmp/deploy/sources, and .spec files in tmp/deploy/rpm/specs. To make translator-specific changes in .bb or .bbappend files, use the "srpm" OVERRIDE: EXTRA_OEMAKE_append_srpm = "foobar" Technical Overview --- At the highest level, meta-translator is essentially a forked source archiver class (archiver.bbclass) which calls out to a SRPM package class (forked from package_rpm.bbclass) The archiver is responsible for collecting all of the source files that are used to build a recipe by invoking the 'fetch' task. It then calls package_srpm to write a spec file and generate a SRPM. Whereas in normal usage package_rpm is used to generate a minimal .spec that can build a binary package, meta-translator generates a more complex .spec that includes the build instructions from the .bb input so that the generated SRPM can be rebuild in another build system (for example, OBS). There are several complications. Package file lists in BitBake are loose, in that files listed don't have to exist and so the default value (set in bitbake.conf) includes many files that are not found in an arbitrarily chosen package. By contract RPM file lists are strict, if a file in the list isn't found then an error is produced. We work around this by requiring that recipes intended for translation need to specify exact file lists through the FILES_ variables in either the recipe or a .bbappend. BitBake dynamically generates shell scripts that are not intended for human consumption, so these have many exports and numerous shell functions. Inserting them directly into the .spec isn't feasible so key functions are replaced with the relevant RPM macro (%configure, %make, etc) and blacklists are used to stop exported selected variables. To Do --- * Implement a spec abstraction for clearer code and convenience for fixup hooks. * Implement SMACK manifest support in a fixup hook. * "Unwrap" shell functions when outputting the build tasks so the generated functions are cleaner. * Add missing tags (BuildArch, probably more). * Translate PACKAGECONFIG settings as bcond. This will mean saving the PACKAGECONFIG value before clearing it, then iterating through the saved values and setting the dependencies and configure options as required.