prunerepo

#9 Optimized run of createrepo_c with --recycle-pkglist
Closed: Fixed by praiskup. Opened by praiskup.

Closed: Fixed
Reopen Issue

There's a new option in createrepo_c called --recycle-pkglist.

That dramatically minimizes I/O, almost to nothing when we speak about. In
case of prunerepo run, it should be used like:
--recycle-pkglist --exclude 'path/package-name.src.rpm'

Something like this is done in Copr when people delete particular builds,
it is good that craterepo_c doesn't have to traverse the whole repository
directory to observe what packages are there (very expensive for very
large repositories).

Hey, is the option documented somewhere? Probably if it can be used, we could use if the createrepo_c version on the system is sufficiently new.

Yep, documentation is in the manual page.

Btw., worth saying here -- it is absolutely expected to run createrepo
first with the --recycle-pkglist option and after that remove the RPM
files (not vice versa). This way it is guaranteed that the repodata
created are valid all the time.

When we remove RPM first, and then we run createrepo_c - there is huge
(with big repos) time window when metadata are still pointing at
non-existing content, causing all kind of repository errors.

Hmpfs, there's a different problem .. we run prunerepo with --nocreaterepo,
which means that it is not possible for us to continue wisely within this concept.

Would it be possible to teach prunerepo to just print-out the list of RPMs that
are to be removed - so copr could first run createrepo (with --exclude) and
do the removal manually?

Hmpfs, there's a different problem .. we run prunerepo with --nocreaterepo,
which means that it is not possible for us to continue wisely within this concept.

Would it be possible to teach prunerepo to just print-out the list of RPMs that
are to be removed - so copr could first run createrepo (with --exclude) and
do the removal manually?

Yes, that seems like a good idea. I guess it should be print rpms as well as corresponding srpms if we manage to optimize srpm deletion (#7) or do you have some other idea?
Edited by clime

I don't have better idea. Perhaps it would be nice to have a python API for this
functionality ... :-) if I could ask.

Hmpfs, there's a different problem .. we run prunerepo with --nocreaterepo,
which means that it is not possible for us to continue wisely within this concept.

Would it be possible to teach prunerepo to just print-out the list of RPMs that
are to be removed - so copr could first run createrepo (with --exclude) and
do the removal manually?

Yes, that seems like a good idea. I guess it should be print rpms as well as corresponding srpms if we manage to optimize srpm deletion (#7) or do you have some other idea?

I would be happy to take care of implementing such an improvement as it will help us speed up some things 🙂

I would be happy to take care of implementing such an improvement as it will help us speed up some things 🙂

Feel free, i am unlikely to find this week.

Commit 44f629b2 fixes this issue

This issue has been migrated to GitHub: https://github.com/fedora-copr/prunerepo/issues/9
Don't forget to subscribe for notifications about new comments.
Metadata
None
None
None
None
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.