flatpak-module-tools

#31 build-rpms-local gets confused by subpackages with different versions
Closed by otaylor. Opened by yselkowitz.

Closed
Reopen Issue

While not common, there are some packages that set different versions for some of its subpackages. (Notable examples of this are musescore, pandoc, perl, perl-Encode, ruby, and texlive/texlive-base.) When built with build-rpms-local, a subsequent build-rpms-local or build-container-local lists the version of the package as a whole based on the version of the last subpackage therein rather than that of the SRPM, which (if the subpackage version is less, which seems to happen in these cases) then makes it think that the local build is outdated and act accordingly.

--allow-outdated is a workaround in the meantime, but it would be helpful to fix this properly.

This was fixed a while ago in git, fix is in the 1.0 release.

commit 403291fa25c20352bb653c9befbc6235db3aa24b
Author: Owen W. Taylor <otaylor@fishsoup.net>
Date:   Fri Dec 1 16:25:24 2023 -0500
    Only use SRPMs when looking up package versions for the local repository
    Instead of getting the version from an arbitrary binary or source RPM,
    always use the source RPM. This is necessary because binary subpackages
    can have a version that is different from source RPM / koji build.
    Resolves: #31

Metadata Update from @otaylor:
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
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.