Bug 1040335 - opescap should provide openscap-content and firstaidkit-plugin-openscap in the package
Summary: opescap should provide openscap-content and firstaidkit-plugin-openscap in th...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: scap-security-guide
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Lieskovsky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-11 08:49 UTC by Diego
Modified: 2014-01-15 06:05 UTC (History)
8 users (show)

Fixed In Version: scap-security-guide-0.1.4-2.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-15 06:05:39 UTC


Attachments (Terms of Use)

Description Diego 2013-12-11 08:49:50 UTC
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."

Comment 1 Šimon Lukašík 2013-12-11 15:03:15 UTC
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?

Comment 2 Jan Lieskovsky 2013-12-12 09:11:35 UTC
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.

Comment 3 Martin Sivák 2013-12-12 10:08:38 UTC
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.

Comment 4 Šimon Lukašík 2013-12-12 10:43:02 UTC
(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!

Comment 5 Martin Sivák 2013-12-18 11:55:28 UTC
> 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).

Comment 6 Jan Lieskovsky 2013-12-18 15:53:45 UTC
(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.

Comment 7 Jan Lieskovsky 2013-12-19 11:02:54 UTC
(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.

Comment 8 Martin Sivák 2013-12-19 13:37:58 UTC
Just an empty subpackage with the Provides.

Comment 9 Jan Lieskovsky 2013-12-19 15:58:26 UTC
(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

Comment 10 Fedora Update System 2013-12-20 18:18:22 UTC
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

Comment 11 Fedora Update System 2013-12-20 18:20:42 UTC
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

Comment 12 Fedora Update System 2013-12-20 18:23:43 UTC
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

Comment 13 Fedora Update System 2013-12-22 05:35:37 UTC
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).

Comment 14 Jan Lieskovsky 2014-01-06 10:18:56 UTC
An issue was found on Fedora 19: http://fpaste.org/63953/

Thanks, Simon.

Comment 15 Fedora Update System 2014-01-06 14:34:18 UTC
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

Comment 16 Fedora Update System 2014-01-06 14:35:37 UTC
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

Comment 17 Fedora Update System 2014-01-06 14:37:05 UTC
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

Comment 18 Fedora Update System 2014-01-07 09:37:48 UTC
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).

Comment 19 Fedora Update System 2014-01-15 06:05:39 UTC
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.

Comment 20 Fedora Update System 2014-01-15 06:05:54 UTC
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.


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