Bug 963679 - iprutils should not be installed/enabled by default
iprutils should not be installed/enabled by default
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: iprutils (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Karsten Hopp
Fedora Extras Quality Assurance
:
Depends On:
Blocks: WhyWeBootSoSlow
  Show dependency treegraph
 
Reported: 2013-05-16 07:29 EDT by Lennart Poettering
Modified: 2015-01-09 18:47 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-09 18:47:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lennart Poettering 2013-05-16 07:29:05 EDT
iprutils is apparently pulled into all instalaltions of F19 now, and enabled there. It really shouldn't be. 

Also see the discussion at

https://lists.fedoraproject.org/pipermail/devel/2013-May/182814.html

Could you find a different way how to handle this? Maybe pull it in from anaconda, only when actually needed? Pull this in from a udev rule when it is actually needed?
Comment 1 Karsten Hopp 2013-05-16 19:03:48 EDT
If I remember correctly I was asked by IBM to enable builds of the iprutils package on all archs. 
But it shouldn't be pulled into a default installation on archs != ppc* IMHO.
Comment 2 Lennart Poettering 2013-05-17 08:35:54 EDT
Well, it currently is listed in the comps group "core". Are you OK if we remove it there?

Bill?
Comment 3 Bill Nottingham 2013-05-20 11:06:19 EDT
I don't think anaconda/yum honor arch= in comps, so just removing it would break power. It should be fixable to not do awful things, though.
Comment 4 Jóhann B. Guðmundsson 2013-06-15 18:14:31 EDT
Bill can we please not add unmigrated unit to comps thanks. 

When we add this to core along with introducing components into the distribution with legacy sysv initscrips feels like we take one step forwards and two steps backwards. 

It's better that you just ping me and I see if I cant migrate that stuff. 

I have now started iprutils migration on bug 974796 also filed RFE to see if we cant add ConditionArch= to solve issues like these and other use cases...
Comment 5 Bill Nottingham 2013-06-17 10:19:45 EDT
(In reply to Jóhann B. Guðmundsson from comment #4)
> Bill can we please not add unmigrated unit to comps thanks. 

It was added to comps many years ago (predates systemd) when it only existed for PPC. It only showed up now because as Karsten said, he started building it for all arches.
Comment 6 Jóhann B. Guðmundsson 2013-06-19 10:32:41 EDT
Should we revert this and remove this from comps for primary arch before final since this is PPC only?
Comment 7 Adam Williamson 2013-06-19 11:50:52 EDT
Looks like Bill's taken it out of comps now. That solves the 'iprutils gets installed when it's no use' problem for primary arches, but presumably causes a problem for Power installs that actually *need* it. Shall we file a new bug for anaconda to conditionally install it on Power or something?
Comment 9 David Woodhouse 2013-06-19 11:55:35 EDT
This conversation confuses me. Why not just fix iprutils so that when there is no relevant hardware present (even if it *is* a ppc64 machine), it does nothing and thus offends nobody? Trigger its startup from udev or something?
Comment 10 Jóhann B. Guðmundsson 2013-06-19 12:00:11 EDT
Why install something that will never be used on the primary arch? 

Anyway the window to migrate units into the release has been closed ( it gets closed on Beta ) which means no udev rule starting the systemd unit. 

Maybe the beta migration rule set by fesco does not apply to secondary arches but to answer your question yes that would be the best way to start it ( hw detected service activated )
Comment 11 David Woodhouse 2013-06-19 12:07:26 EDT
(In reply to Jóhann B. Guðmundsson from comment #10)
> Why install something that will never be used on the primary arch? 

A fair question, but not one which should distract us from implementing the *correct* fix. I'd guess that is closely tied to "why did we recently start building this on all architectures instead of just ppc". Did the hardware start to show up on other boxes? If it's just a PCI device that was always possible, right?

The correct fix will avoid the problem also on other ppc64 hardware which doesn't have ipr.
Comment 12 Adam Williamson 2013-06-19 12:09:41 EDT
"I'd guess that is closely tied to "why did we recently start building this on all architectures instead of just ppc"."

A question that's partly answered in this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=963679#c1

"If I remember correctly I was asked by IBM to enable builds of the iprutils package on all archs."

Apart from that, we have no indication any of the hardware actually exists for any other arch. This fix is as 'correct' as any: it's absurd for a package that is useless on 99.9% of Fedora installs to be in the 'core' comps group. Even if we fix it to only actually run if the hardware's present, if we leave it in @core it is needlessly inflating the size of the minimal install, which is already subject to gradual creep (it's grown by 40 packages since f16, I am currently doing a comparison).
Comment 13 Fedora End Of Life 2015-01-09 17:33:43 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 14 Adam Williamson 2015-01-09 18:47:00 EST
well, it's stayed dropped from comps since f18, so let's close.

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