Description of problem: irqbalance now uses the libnuma. irqbalance is always installed by default. -> numactl is always installed by default. -> perl is always installed by default. That's bad (and causes size issues on the live images.) Options include: 1) rewrite numastat in C/shell 2) split libnuma out of numactl (numactl-libs?) Version-Release number of selected component (if applicable): numactl-2.0.7-4.fc17.x86_64 irqbalance-1.0.3-3.fc17.x86_64 How reproducible: 100% Steps to Reproduce: 1. Grab a recent F17 live image 2. Look for perl Actual results: Perl. Expected results: No Perl.
Bill, if it's bad only for the live images, why not to fix the "irqbalance is always installed by default" ? I don't think folks who're using live images pay much attention to performance. thoughts?
The point of irqbalance is for SMP systems, and most everything is a SMP system, so I don't see why we wouldn't/shouldn't provide it. Splitting the libs off is probably the simplest, something like: diff --git a/numactl.spec b/numactl.spec index 92756d9..cda2828 100644 --- a/numactl.spec +++ b/numactl.spec @@ -15,13 +15,20 @@ ExcludeArch: s390 s390x %{arm} %description Simple NUMA policy support. It consists of a numactl program to run -other programs with a specific NUMA policy and a libnuma to do -allocations with NUMA policy in applications. +other programs with a specific NUMA policy. + +%package libs +Summary: libnuma libraries +Group: System Environment/Libraries + +%description libs +numactl-libs provides libnuma, a library to do allocations with +NUMA policy in applications. %package devel Summary: Development package for building Applications that use numa Group: System Environment/Libraries -Requires: %{name} = %{version}-%{release} +Requires: %{name}-libs = %{version}-%{release} %description devel Provides development headers for numa library calls @@ -46,13 +53,12 @@ make prefix=$RPM_BUILD_ROOT/usr libdir=$RPM_BUILD_ROOT/%{_libdir} install %clean rm -rf $RPM_BUILD_ROOT -%post -p /sbin/ldconfig +%post libs -p /sbin/ldconfig -%postun -p /sbin/ldconfig +%postun libs -p /sbin/ldconfig %files %defattr(-,root,root,-) -%{_libdir}/libnuma.so.1 %{_bindir}/numactl %{_bindir}/numademo %{_bindir}/numastat @@ -61,6 +67,11 @@ rm -rf $RPM_BUILD_ROOT %{_bindir}/migratepages %{_mandir}/man8/*.8* +%files libs +%defattr(-,root,root,-) +%{_libdir}/libnuma.so.1 + + %files devel %defattr(-,root,root,-) %{_libdir}/libnuma.so would theoretically work.
*** Bug 800142 has been marked as a duplicate of this bug. ***
800142 was nominated as a final blocker, so transferring that here. However, Adam, could you expand on the justification for this blocking release? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #0) > > Options include: > 1) rewrite numastat in C/shell > 2) split libnuma out of numactl (numactl-libs?) > Also voting for option 2). If all of you will agree, I would start off with package splitting according to Bill's suggestion in comment #2.
Option 2 sounds fine. As for "blocker" I mostly don't want to see us regressing the live image size more than we need to, and we've managed to ship it without perl for I think two releases now. If there's a better place for "this really should get done" bugs to go, fine.
"One of the release-blocking live images is above its specified maximum size" would indeed be a release blocker, but in point of fact, neither of them is. Desktop has been way under size for several releases, it's currently (as of Beta TC2) 640MB. KDE is 687MB. Both comfortably under 700MB. I'm not gonna say "there's a better place for "this really should get done" bugs" exactly - we don't really have a central system for tracking such, if anything, you're meant to use Bugzilla priorities for it - but nevertheless, we can't really (ab)use the release validation process to that end. Blocker status is used for a specific purpose, under a pretty strongly defined process and policy, and it achieves that purpose well. We have to stick strictly to the process / policy to ensure that's the case. So, er, sorry about that :) Unless we find something in the release criteria that this bug actually violates, it won't be accepted as a blocker. If we start accepting any kind of 'we really want to get this done' bug as a 'blocker' we'll go back to the days where, when push comes to shove, we just say 'only kidding!' and never actually block the release, in which case you may as well not have a blocker system at all. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
What objections are there to option #2? We're looking at putting some more software on the live image, and we may need the space.
ping, some decision?
If you're asking me, just doing something like the patch in comment #2 would be fine.
(Consider that a request to please do just that.)
numactl-2.0.7-5.fc17,irqbalance-1.0.3-4.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/numactl-2.0.7-5.fc17,irqbalance-1.0.3-4.fc17
I've splitted libnuma out of numactl as Bill proposed in comment #2 and notified maintainers of dependent packages libvirt and hwloc about this change. Update was submitted to Bodhi as bundle of new numactl and irqbalance - is it enough or hwloc and libvirt should be added to update too? thanks, Petr H
If they just require the library via a soname dependency, they shouldn't need updating at all; the right thing should happen.
Package numactl-2.0.7-5.fc17, irqbalance-1.0.3-4.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing numactl-2.0.7-5.fc17 irqbalance-1.0.3-4.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-5968/numactl-2.0.7-5.fc17,irqbalance-1.0.3-4.fc17 then log in and leave karma (feedback).
Discussed at 2012-04-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-04-20/fedora-bugzappers.2012-04-20-17.01.log.txt . The proposed new release criterion 'Perl is a blocker' failed to pass by a small margin, so this is rejected as a blocker. ;) Seriously, this is rejected as a blocker under the reasoning in comment #7. If the perl thing was enough to drive an image over its specified size, this would be a blocker, but it is not.
numactl-2.0.7-5.fc17, irqbalance-1.0.3-4.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.