Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1702771 - Incorrect createrepo RPM file in fedora 29
Summary: Incorrect createrepo RPM file in fedora 29
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: createrepo
Version: 29
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Michal Domonkos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-24 17:47 UTC by Christopher Beer
Modified: 2019-07-16 03:21 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-16 03:21:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Christopher Beer 2019-04-24 17:47:08 UTC
Description of problem:
I cannot install createrepo on my fedora 29 system using dnf. The issue is that the fedora 28 file is stored in the fedora 29 repo. When I navigate to:

​http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/releases/29/Everything/x86_64/os/Packages/c/​

​the file listed is: createrepo-0.10.3-15.fc28.noarch.rpm

Version-Release number of selected component (if applicable):
Fedora 29 (4.19.14-300.fc29.x86_64)

How reproducible:
Always

Steps to Reproduce:
1. Install fedora29 on a system
2. Run 'dnf list createrepo'

Actual results:
Available Packages
createrepo.noarch                     0.10.3-15.fc28                      fedora


Expected results:
Available Packages
createrepo.noarch                     0.12.2-1.fc29                       fedora


Additional info:
The same issue exists in the fedora 30 repo (http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/development/30/Everything/x86_64/os/Packages/c/).

Comment 1 Michal Domonkos 2019-05-20 14:05:07 UTC
The legacy createrepo (not to be confused with createrepo_c) has been deprecated and is already gone from Rawhide:
https://src.fedoraproject.org/rpms/createrepo/c/0cd7846754c5179a41bfdc4fdd61cfa440af8122?branch=master

That said, there's no point in rebuilding it for F30 at this point.  Please use createrepo_c instead ("dnf install createrepo" picks that one by default as well).

Comment 2 Christopher Beer 2019-05-20 15:09:09 UTC
To fix this the Fedora 28 RPM _needs_to_be_removed_ from the Fedora 29 and Fedora 30 packages. 

I provided links to the 29 & 30 packages, and I can clearly see that the Fedora 28 package for createrepo is still there.

Comment 3 Adam Williamson 2019-05-24 17:12:31 UTC
This cannot be fixed in the way proposed. The release repositories are frozen, they are not modified by policy. What is in them, is in them for all time. Note, there is an assumption here that an F28-versioned package being in an F29 repo is a bug: it is not, this happens all the time, for packages that fail mass rebuild or aren't included in the mass rebuild. *In itself* there is nothing wrong with this; there is nothing inherently wrong with the 'createrepo' package in F29 being one from the F28 era, if that package works OK. There never was a successful F29 or F30-era build of createrepo, but this in itself is not really a problem exactly.

If there's a real problem here, it's that the migration from createrepo to createrepo_c has been somewhat muffed in F29 and F30.

The frozen F29 and F30 release repos contain createrepo_c packages that Obsoletes: and Provides: createrepo. Later on, Pavla Kratochvilova decided that createrepo_c obsoleting createrepo was a mistake for these releases and sent out updates that remove the Obsoletes and Provides for releases earlier than F31, but this did not have the effect that Pavla thought it would. Because the older createrepo_c that obsoletes createrepo is *still in* the frozen release repo, when you upgrade from an older release to F29 or F30 currently, createrepo is still replaced by createrepo_c - just by the older version in the frozen repo, rather than the newer version in the updates repo. On the next system update, the old version will be updated to the version from the updates repo. (Note, this is why createrepo_c updates for F29 and F30 always fail a couple of openQA tests.)

I'd suggest that, as we can never take the createrepo_c packages with Obsoletes: and Provides: out of the frozen release repos anyway, the Obsoletes: and Provides: should be restored to current F29 and F30 builds of createrepo_c, so this weird two-stage thing doesn't occur (and the openQA tests pass). The other way to make things 'consistent' here would be to do a fake 0.11.0-versioned build of the old 'createrepo' for F29 and F30; as the Obsoletes are versioned "< 0.11.0", this would make them no longer take effect, and make 'createrepo' a current package for both releases again.

Comment 4 Michal Domonkos 2019-05-27 15:56:05 UTC
Fixed upstream:
https://github.com/rpm-software-management/createrepo_c/pull/162

Comment 5 Michal Domonkos 2019-05-27 15:58:02 UTC
Note that I have "hijacked" this BZ to fix the broken migration path described by Adam above.  The original issue reported in this BZ is already considered fixed.

Comment 6 Fedora Update System 2019-06-27 14:23:25 UTC
FEDORA-2019-4448e01a41 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4448e01a41

Comment 7 Fedora Update System 2019-06-28 21:44:19 UTC
createrepo_c-0.14.2-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4448e01a41

Comment 8 Fedora Update System 2019-07-16 03:21:59 UTC
createrepo_c-0.14.2-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.