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.
BZ#1251095 dnf doesn't discover undefined %epoch broken dep
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.
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.
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
https://lists.fedoraproject.org/pipermail/devel/2015-October/216047.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.
This update has been pushed to testing.
works for me
This update has been submitted for stable by bodhi.
Works for me.
This update has been pushed to stable.