The utility for building of AlmaLinux distributions (repos, ISO images).
Go to file
Qixiang Wan b81e94e808 image-build: add arch name(s) in image config file name
Pungi write image config file with name of <format>-<name>.cfg, if there
are two or more image configs present for different arches under the same
variant and with same format & name, the config file can be overwritten,
and result in invalid image conf file.

Example:

image_build = {
    '^Server$': [
        {
            'image-build': {
                'format': [('qcow2', 'qcow2'),],
                'name': 'fedora-guest-image',
                'target': 'guest-fedora-26-image',
                'version': '26',
                'ksurl': "git://git.example.com/ks.git?fedora#HEAD",
                'kickstart': "fedora-26-kvm.ks",
                'ksversion': 'f26',
                'distro': 'fedora-26',
                'disk-size': '10',
                'arches': ['x86_64'],
                'repo': ["http://example.com/linux/fedora/26/Everything/x86_64/os", ]
            }
        },
        {
           'image-build': {
                'format': [('qcow2', 'qcow2'),],
                'name': 'fedora-guest-image',
                'target': 'guest-fedora-26-image',
                'version': '26',
                'ksurl': "git://git.example.com/ks.git?fedora#HEAD",
                'kickstart': "fedora-26-kvm.ks",
                'ksversion': 'f26',
                'distro': 'fedora-26',
                'disk-size': '10',
                'arches': ['ppc64le'],
            }
        },
    ],
}

In this case, config file "qcow2_guest-fedora-26-image.cfg" will be
created for both x86_64 and ppc64le under the same variant dir, and
there is a high chance it will be over-written while Pungi creating the
koji task. We can add arch name(s) in config filename to avoid that.

Signed-off-by: Qixiang Wan <qwan@redhat.com>
2017-09-03 23:51:08 +08:00
bin Open files as binary where needed 2017-08-28 13:47:18 +02:00
contrib/yum-dnf-compare gather: Only parse pungi log once 2017-08-09 11:04:14 +02:00
doc config: Allow setting default compose type 2017-08-25 10:07:33 +02:00
pungi image-build: add arch name(s) in image config file name 2017-09-03 23:51:08 +08:00
pungi_utils unified-iso: Only link to non-empty variants 2017-07-31 15:15:17 +02:00
share Add support for modular composes 2017-03-22 15:55:52 +01:00
tests image-build: add arch name(s) in image config file name 2017-09-03 23:51:08 +08:00
.gitignore Update makefile targets for testing 2016-02-23 13:03:11 +01:00
AUTHORS extra-files: Write a metadata file enumerating extra files 2016-09-07 13:02:48 +02:00
COPYING Remove FSF address from comments 2016-09-23 10:26:43 +02:00
git-changelog Use Python 3 print function 2017-08-23 09:41:22 +02:00
GPL Update GPL to latest version from https://www.gnu.org/licenses/gpl-2.0.txt 2015-06-25 07:50:03 -04:00
Makefile Extract only first version from specfile 2017-03-06 09:08:13 +01:00
MANIFEST.in setup: Update manifest to include doc images 2017-07-17 09:26:20 +02:00
pungi.spec Check for correct string class 2017-08-28 14:31:09 +02:00
README.md Add README 2016-03-08 16:38:40 +01:00
RELEASE-NOTES Rename product_* to release_*. 2015-07-09 06:58:30 -04:00
setup.py Check for correct string class 2017-08-28 14:31:09 +02:00
TODO Initial code merge for Pungi 4.0. 2015-02-10 08:19:34 -05:00
tox.ini Ignore more pycodestyle warnings 2017-06-14 13:21:31 +02:00

Pungi

Pungi is a distribution compose tool.

Composes are release snapshots that contain release deliverables such as:

  • installation trees
    • RPMs
    • repodata
    • comps
  • (bootable) ISOs
  • kickstart trees
    • anaconda images
    • images for PXE boot

Tool overview

Pungi consists of multiple separate executables backed by a common library.

The main entry-point is the pungi-koji script. It loads the compose configuration and kicks off the process. Composing itself is done in phases. Each phase is responsible for generating some artifacts on disk and updating the compose object that is threaded through all the phases.

Pungi itself does not actually do that much. Most of the actual work is delegated to separate executables. Pungi just makes sure that all the commands are invoked in the appropriate order and with correct arguments. It also moves the artifacts to correct locations.