The utility for building of AlmaLinux distributions (repos, ISO images).
4f69f6c242
The pkgset phase takes around 35 minutes in current composes. Around 20 minutes of that is spent creating these per-arch subsets of the global package set. In a rather roundabout way (see #1794 ), I figured out that almost all of this time is spent in this cache check, which is broken for a subtle reason. Python's `in` keyword works by first attempting to call the container's magic `__contains__` method. If the container does not implement `__contains__`, it falls back to iteration - it tries to iterate over the container until it either hits what it's looking for, or runs out. (If the container implements neither, you get an error). The FileCache instance's `file_cache` is a plain Python dict. dicts have a very efficient `__contains__` implementation, so doing `foo in (somedict)` is basically always very fast no matter how huge the dict is. FileCache itself, though, implements `__iter__` by returning an iterator over the `file_cache` dict's keys, but it does *not* implement `__contains__`. So when we do `foo in self.file_cache`, Python has to iterate over every key in the dict until it hits foo or runs out. This is massively slower than `foo in self.file_cache.file_cache`, which uses the efficient `__contains__` method. Because these package sets are so huge, and we're looping over *one* huge set and checking each package from it against the cache of another, increasingly huge, set, this effect becomes massive. To make it even worse, I ran a few tests where I added a debug log if we ever hit the cache, and it looks like we never actually do - so every check has to iterate through the entire dict. We could probably remove this entirely, but changing it to check the dict instead of the FileCache instance makes it just about as fast as taking it out, so I figured let's go with that in case there's some unusual scenario in which the cache does work here. Signed-off-by: Adam Williamson <awilliam@redhat.com> (cherry picked from commit c8fe99b1aa5a9a9b941b7515cda367d24829dedf) |
||
|---|---|---|
| contrib | ||
| doc | ||
| pungi | ||
| pungi_utils | ||
| share | ||
| tests | ||
| .gitignore | ||
| 1860.patch | ||
| AUTHORS | ||
| COPYING | ||
| git-changelog | ||
| GPL | ||
| Makefile | ||
| MANIFEST.in | ||
| pungi.spec | ||
| README.md | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| sources | ||
| test-requirements.txt | ||
| TODO | ||
| tox.ini | ||
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
- Documentation: https://docs.pagure.org/pungi/
- Upstream GIT: https://pagure.io/pungi/
- Issue tracker: https://pagure.io/pungi/issues
- Questions can be asked in the #fedora-releng IRC channel on irc.libera.chat
or in the matrix room
#releng:fedoraproject.org