Red Hat Bugzilla – Bug 963679
iprutils should not be installed/enabled by default
Last modified: 2015-01-09 18:47:00 EST
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?
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.
Well, it currently is listed in the comps group "core". Are you OK if we remove it there? Bill?
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.
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...
(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.
Should we revert this and remove this from comps for primary arch before final since this is PPC only?
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?
https://git.fedorahosted.org/cgit/comps.git/commit/?id=9c1100a043cfd225f5b9dffe22b4df943afec63f
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?
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 )
(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.
"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).
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.
well, it's stayed dropped from comps since f18, so let's close.