Bug 799132 - numastat is written in perl
Summary: numastat is written in perl
Alias: None
Product: Fedora
Classification: Fedora
Component: numactl
Version: 17
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Petr Holasek
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker
: 800142 (view as bug list)
Depends On:
Blocks: 799144
TreeView+ depends on / blocked
Reported: 2012-03-01 20:35 UTC by Bill Nottingham
Modified: 2016-10-04 04:08 UTC (History)
6 users (show)

Fixed In Version: numactl-2.0.7-5.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-05-02 20:54:39 UTC
Type: ---

Attachments (Terms of Use)

Description Bill Nottingham 2012-03-01 20:35:43 UTC
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):


How reproducible:


Steps to Reproduce:
1. Grab a recent F17 live image
2. Look for perl
Actual results:


Expected results:

No Perl.

Comment 1 Anton Arapov 2012-03-02 08:20:14 UTC
  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.


Comment 2 Bill Nottingham 2012-03-02 16:49:35 UTC
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}
 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
-%post -p /sbin/ldconfig
+%post libs -p /sbin/ldconfig
-%postun -p /sbin/ldconfig
+%postun libs -p /sbin/ldconfig
@@ -61,6 +67,11 @@ rm -rf $RPM_BUILD_ROOT
+%files libs
 %files devel

would theoretically work.

Comment 3 Anton Arapov 2012-03-05 20:46:51 UTC
*** Bug 800142 has been marked as a duplicate of this bug. ***

Comment 4 Adam Williamson 2012-03-05 23:01:43 UTC
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

Comment 5 Petr Holasek 2012-03-06 08:10:48 UTC
(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.

Comment 6 Adam Jackson 2012-03-12 14:21:53 UTC
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.

Comment 7 Adam Williamson 2012-03-12 22:15:11 UTC
"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

Comment 8 Bill Nottingham 2012-03-27 18:11:55 UTC
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.

Comment 9 Petr Holasek 2012-04-04 08:33:33 UTC
ping, some decision?

Comment 10 Bill Nottingham 2012-04-12 18:47:48 UTC
If you're asking me, just doing something like the patch in comment #2 would be fine.

Comment 11 Bill Nottingham 2012-04-12 19:12:05 UTC
(Consider that a request to please do just that.)

Comment 12 Fedora Update System 2012-04-16 13:08:19 UTC
numactl-2.0.7-5.fc17,irqbalance-1.0.3-4.fc17 has been submitted as an update for Fedora 17.

Comment 13 Petr Holasek 2012-04-16 13:23:54 UTC
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?

Petr H

Comment 14 Bill Nottingham 2012-04-16 17:41:06 UTC
If they just require the library via a soname dependency, they shouldn't need updating at all; the right thing should happen.

Comment 15 Fedora Update System 2012-04-16 21:55:01 UTC
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:
then log in and leave karma (feedback).

Comment 16 Adam Williamson 2012-04-20 20:44:24 UTC
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.

Comment 17 Fedora Update System 2012-05-02 20:54:39 UTC
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.

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