FEDORA-2015-735f979d01

enhancement update in Fedora 22 for createrepo_c

Status: stable 3 years ago

Several bug fixes

Comments 16

This update has been submitted for testing by tmlcoch.

The "fix" attempt for bug 1251095 makes my head hurt. By skipping such a broken dependency (i.e. not adding it to the repo metadata!), depsolvers and tools like repoclosure cannot find the unresolvable dep when searching the metadata. Only during RPM's transaction check, the breakage will be discovered. As before. Same symptoms. So, not fixed.

In the ideal case, the repo metadata would not hide the problem, so it could be detected by QA tools.

#1251095: -1

While this update does indeed fix the DeltaRPM support and add support for creating xml.xz metadata, I tend to agree with @mschwendt about the way #1251095 was "resolved".

There doesn't appear to be a way for tools built around createrepo_c to correctly handle this issue.

I would consider one of these to be valid solutions:

  • Do not generate the metadata after going through all the packages and returning the error for tools/people to handle. In this case, there would be no metadata for anything to consume because createrepo_c wouldn't make any as long as there are errors in the package data.

  • Add them in anyway, but add some kind of tag indicating that it's a badly written package, and corrections are required. Some repodata validation tool could handle this and return the information appropriately. Likewise, DNF could have code written to handle detection of this particular tag and deal with it differently.

We cannot allow broken dependency chains to exist, in any form.

@mschwendt @ngompa Read my comment about "the bug" here: https://lists.fedoraproject.org/pipermail/devel/2015-August/213882.html Especially the bullet no. 1 and its cons and why the solution you suggest wasn't implemented - createrepo_c tends to be part of critical systems for delivering updates - we just cannot break whole update system and require manual releng action just because some maintainer of some foobar package did a typo in spec of package which is used by two people in the world (where one is the maintainer itself and the second one is a person who installed it by mistake). There is no "problem hiding" - warning is printed. If you are providing invalid input you cannot expect valid output.

If you are able to recognize the input as being invalid, you can exit with error condition. Unfortunately, you choose to skip/ignore input that is detected as being invalid. I've sent a reply to devel@ list.

@mschwendt, Ideally yes. But createrepo_c is used in places where this would cause problems - see my reply on devel list https://lists.fedoraproject.org/pipermail/devel/2015-October/216015.html

@mschwendt, this looks like the undefined epoch thing can't even happen anymore...

Exactly. It's the response to rpmbuild bug 1251453 I had filed. More details in that ticket.

In that case, I'll give it a +1 for this update.

#1251095: +1

This update has been pushed to testing.

works for me

karma: +1

This update has been submitted for stable by bodhi.

Works for me.

karma: +1

This update has been pushed to stable.

Add Comment & Feedback

Please login to add feedback.

Content Type
RPM
Status
stable
Test Gating
Submitted by
Update Type
enhancement
Update Severity
unspecified
Karma
+3
stable threshold: 3
unstable threshold: -3
Autopush (karma)
Enabled
Autopush (time)
Disabled
Dates
submitted 3 years ago
in testing 3 years ago
in stable 3 years ago

Related Bugs 3

0+1 #1251095 dnf doesn't discover undefined %epoch broken dep
00 #1253850 [rfe] Add --xml-xz to createrepo_c to generate xz compressed XML metadata
00 #1261031 createrepo_c cannot generate DeltaRPMs even when compiled with drpm

Automated Test Results