This is a copy of bug #1039899 but assigned to openscap. Description of problem: yum upgrade fails because of a dependency fail. How reproducible: Always Steps to Reproduce: 1. run "yum upgrade" in Fedora 19 Actual results: At the end you get: Error: Package: firstaidkit-plugin-openscap-0.3.2-6.fc19.noarch (@fedora) Requires: openscap-content >= 0.7.2 Removing: openscap-content-0.9.12-1.fc19.noarch (@updates) openscap-content = 0.9.12-1.fc19 Obsoleted By: scap-security-guide-0.1-3.1.fc19.noarch (updates) Not found Available: openscap-content-0.9.7-1.fc19.noarch (fedora) openscap-content = 0.9.7-1.fc19 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Like reported in: https://bugzilla.redhat.com/show_bug.cgi?id=1028706#c10 Expected results: yum upgrade succeeds. Proposed solution: Martin of firstaidkit suggests: https://bugzilla.redhat.com/show_bug.cgi?id=1034949#c5 "They can (and should) provide openscap-content and firstaidkit-plugin-openscap in their new package. That way the package will be removed when you install scap-security-guide."
It is unfortunate. If only firstaidkit was not dead, we could amend its requires. Nevertheless, from OpenSCAP point of view not much can be done. OpenSCAP does no longer provide openscap-content. In fact, scap-security-guide does. OpenSCAP packagers cannot assert that openscap obsoletes a certain version of firstaidkit, because it does not. And OpenSCAP packagers cannot assure that there will be no other greater versions. Also, when openscap base package (which is arch dependent) were obsoleting noarch package (firstaidkit-plugin-openscap), it would pull bunch of 32bit packages (see bug 1028706). Perhaps, the scap-security-guide package could provide openscap-content >= 0.7.2 making firstaidkit happy?
Cc-ing Martin yet. (In reply to Šimon Lukašík from comment #1) > It is unfortunate. If only firstaidkit was not dead, we could amend its > requires. Why not to change firstaidkit-plugin-openscap Requires to scap-security-guide? %package plugin-openscap Group: Applications/System Summary: OpenSCAP plugin for FirstAidKit Requires: %{name} = %{version}-%{release} Requires: openscap-python >= 0.7.2 Requires: openscap-content >= 0.7.2 BuildArch: noarch Replace openscap-content with scap-security-guide. > > Nevertheless, from OpenSCAP point of view not much can be done. OpenSCAP > does no longer provide openscap-content. In fact, scap-security-guide > does. OpenSCAP packagers cannot assert that openscap obsoletes a certain > version of firstaidkit, because it does not. And OpenSCAP packagers > cannot assure that there will be no other greater versions. Also, when > openscap base package (which is arch dependent) were obsoleting noarch > package (firstaidkit-plugin-openscap), it would pull bunch of 32bit > packages (see bug 1028706). > > Perhaps, the scap-security-guide package could provide > > openscap-content >= 0.7.2 > > making firstaidkit happy? I can do this in next version, but prior doing that would appreciate opinion if that's really the thing we want (IOW not rather want to change f-p-o to require scap-security-guide instead). Either way works for me. Thanks, Jan.
Firstaidkit is deprecated and maintaining it does not make any sense because all functionality is provided by openscap and there is no wider adoption in the community. Btw renaming a package without checking dependencies first was not a good move. If you still provide the same API and files, you should add the Provides to spec file.
(In reply to Martin Sivák from comment #3) > Firstaidkit is deprecated and maintaining it does not make any sense because > all functionality is provided by openscap and there is no wider adoption in > the community. > I see. We don't ask for maintaining firstaidkit. However it still seems to be the most correct way to actually patch firstaidkit.spec to drop firstaidkit-plugin-openscap. (Obsoleting sub-package from main package seems to be preferred way for dropping a functionality). > Btw renaming a package without checking dependencies first was not a good > move. It wasn't renaming from start. And checking first wouldn't change the decision to drop openscap-content. But you are right, we could do better. > If you still provide the same API and files, you should add the Provides > to spec file. The problem is that scap-security-guide does not provide the exactly the same what openscap-content did. Hence, firstaidkit-plugin-openscap will probably not work using scap-security-guide. Ideally, scap-security-guide shall not provide openscap-content. It is only next generation of a content with some functionality overlap. But we would need to drop openscap-content, even if there was no scap-security-guide. The content was hugely outdated given systemd and usr-move changes. Martin, would it be possible to drop firstaidkit-plugin-openscap from firstaidkit? Thanks!
> However it still seems to be the most correct way to actually patch > firstaidkit.spec to drop firstaidkit-plugin-openscap. Yes, but in that case you should still provide the openscap-content package until this step is finished. > The content was hugely outdated given systemd and usr-move changes. But it was still required by other package. Any application using it would give bad results, but keep working (technically). The way you did it - obsoleting the package without replacement - you broke the upgrade path. So I propose you put openscap-content and firstaidkit-plugin-openscap Provides to a "compat" temporary subpackage of the scap-guide. This way you can fix this with about four lines in spec file without both of us having to resurrect a dead package (I am not sure if that is even possible).
(In reply to Martin Sivák from comment #5) > > However it still seems to be the most correct way to actually patch > > firstaidkit.spec to drop firstaidkit-plugin-openscap. > > Yes, but in that case you should still provide the openscap-content package > until this step is finished. > > > The content was hugely outdated given systemd and usr-move changes. > > But it was still required by other package. Any application using it would > give bad results, but keep working (technically). The way you did it - > obsoleting the package without replacement - you broke the upgrade path. > > So I propose you put openscap-content and firstaidkit-plugin-openscap > Provides to a "compat" temporary subpackage of the scap-guide. This way you > can fix this with about four lines in spec file without both of us having to > resurrect a dead package (I am not sure if that is even possible). Thanks, Martin. Will look at this proposal if feasible to happen in scap-security-guide. Previously tried to avoid fixing SSG rpm instead of firstaidkit, as wasn't sure virtual provides couldn't break even more things (Simon mentioned it above already) rather than to fix this problem. But will give it a try, test, and in case of success apply that proposal. In that case firstaidkit resurrection wouldn't be needed. Thanks, Jan.
(In reply to Martin Sivák from comment #5) Martin, yet one check with you due this yet (to confirm I got it correctly). > So I propose you put openscap-content and firstaidkit-plugin-openscap > Provides to a "compat" temporary subpackage of the scap-guide. This way you > can fix this with about four lines in spec file without both of us having to > resurrect a dead package (I am not sure if that is even possible). You propose ssg-compat package it to just list openscap-content and firstaidkitplugin-openscap in Provides section or propose ssg-compat package, having the former Provides but together with that also provide former / previous content of openscap-content package? (like those XCCDF files to be listed in the files section of ssg-compat too) Thanks, Jan.
Just an empty subpackage with the Provides.
(In reply to Martin Sivák from comment #8) > Just an empty subpackage with the Provides. Thanks. Link to proposed upstream patch: [1] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-December/004733.html
scap-security-guide-0.1.4-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/scap-security-guide-0.1.4-1.fc18
scap-security-guide-0.1.4-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/scap-security-guide-0.1.4-1.fc19
scap-security-guide-0.1.4-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/scap-security-guide-0.1.4-1.fc20
Package scap-security-guide-0.1.4-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing scap-security-guide-0.1.4-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23774/scap-security-guide-0.1.4-1.fc19 then log in and leave karma (feedback).
An issue was found on Fedora 19: http://fpaste.org/63953/ Thanks, Simon.
scap-security-guide-0.1.4-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/scap-security-guide-0.1.4-2.fc18
scap-security-guide-0.1.4-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/scap-security-guide-0.1.4-2.fc19
scap-security-guide-0.1.4-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/scap-security-guide-0.1.4-2.fc20
Package scap-security-guide-0.1.4-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing scap-security-guide-0.1.4-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0284/scap-security-guide-0.1.4-2.fc20 then log in and leave karma (feedback).
scap-security-guide-0.1.4-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
scap-security-guide-0.1.4-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.