almalinux/pungi
15
1
Fork 0
Code Issues Pull Requests Releases Activity
The utility for building of AlmaLinux distributions (repos, ISO images).
2,511 Commits 3 Branches 365 Tags 9.1 MiB
Python 99.4%
XSLT 0.3%
Shell 0.2%
Makefile 0.1%
a435fd58da
Go to file
Lubomír Sedlář a435fd58da gather: Add all srpms to variant lookaside repo 
The original code could cause a source RPM to be present in two variants
that have a dependency relation.

There is always only one source repo for a variant in the final compose.
When gathering packages for a variant that depends on another variant,
we need to build a temporary lookaside repo that has similar content to
the parent variant. This lookaside only contained source RPMs for
packages present the the architecture.

This could result in duplicated SRPMs in the compose.

Example situation:

 * Variant B depends on variant A.
 * A contains foo.x86_64.rpm (only on x86_64)
 * B pulls in subpackage foo-bar.s390x.rpm (on s390x)

Source repo for A will correctly contain foo.src.rpm. With original code
the srpm would also end up in B.src. By adding all sources to the
temporary lookaside Pungi will know that source repo for B doesn't need
to duplicate the package.

The refactoring to use a set to store the packages is meant to avoid
listing the same SRPM multiple times in the repo in the most common
situation when SRPM is listed in multiple architectures.

JIRA: RHELCMP-6002
Signed-off-by: Lubomír Sedlář <lsedlar@redhat.com>
2021-07-19 14:12:44 +02:00
contrib/yum-dnf-compare gather: Only parse pungi log once 2017-08-09 11:04:14 +02:00
doc 4.2.9 release 2021-04-29 06:59:45 +02:00
pungi gather: Add all srpms to variant lookaside repo 2021-07-19 14:12:44 +02:00
pungi_utils Format code 2021-03-02 18:31:45 +08:00
share Allow setting <kojitag/> in <modules/> in variants.xml to get the modules from this Koji tag. 2018-03-21 14:33:45 +01:00
tests util: Strip file:// from local urls 2021-05-06 12:37:55 +02:00
.gitignore Run flake8 and black via tox 2020-02-07 16:14:45 +08: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 git-changelog: Fix running on Python 3 2019-07-02 15:05:25 +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 Use pytest instead of nosetests 2020-07-29 14:57:16 +08:00
MANIFEST.in Include all test fixtures in source tarball 2018-10-17 10:09:46 +02:00
pungi.spec 4.2.9 release 2021-04-29 06:59:45 +02:00
README.md README: add link to documentation 2019-02-18 14:36:48 -07:00
requirements.txt doc: Update doc/contributing.rst 2020-08-11 20:36:22 +08:00
setup.py 4.2.9 release 2021-04-29 06:59:45 +02:00
test-requirements.txt Use requirements.txt 2020-08-11 20:36:22 +08:00
TODO Initial code merge for Pungi 4.0. 2015-02-10 08:19:34 -05:00
tox.ini Use requirements.txt 2020-08-11 20:36:22 +08:00

README.md

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.

Links