psrinfo check in configure requires eval on Solaris

[Tim Mooney]

I'm back to working on building RPM on x86_64-pc-solaris2.11 (OpenIndiana 151a8), this time from CVS. I hope to have a devtool.conf entry for you soon, but in the meantime...

configure from both CVS (as of 20131016) and rpm-5.4.12 has issues on Solaris when trying to determine the # of processors:

=== INSTALLATION PARAMETERS ===
checking root's primary group... root
checking how to determine NCPUS... psrinfo: processor |: Invalid argument
psrinfo: processor egrep: Invalid argument
psrinfo: processor 'on-line': Invalid argument
psrinfo: processor |: Invalid argument
psrinfo: processor wc: Invalid argument
psrinfo: processor -l: Invalid argument
psrinfo: processor |: Invalid argument
psrinfo: processor sed: Invalid argument
psrinfo: processor -e: Invalid argument
psrinfo: processor 's+^: Invalid argument
psrinfo: processor *++': Invalid argument
`psrinfo | egrep 'on-line' | wc -l | sed -e 's+^ *++'` ()

The issue is that the NCPUS_COMMAND that's defined in the case statement isn't actually being eval'ed by the backticks.
There are two possible fixes:

1) just insert an "eval" in front of $NCPUS_COMMAND in the backticks. That does the trick for Solaris, and it doesn't seem to cause any issues on Linux either. I can't easily test freebsd or darwin.

2) instead of defining the command in the case and then running the command after the case, just expand what the case statement does, actually gathering the results there too.

I chose option #1 for the attached patch, but I could easily provide a patch that instead does option #2.

[Jeff Johnson (n3npq)]

Applied.

The real problem here is that commands executed on the build machine,
particularly at the level of NCPUS, are mostly irrelevant to client installs.

The further issue is that NCPUS is a "soft" command: its trivial to conceive
a need for uniprocessor builds on a multi-processor machine, i.e. the actual
NCPUS is most irrelevant/naive to how the NCPUS value is actually used.

Portability for commands determining per-os NCPUS is a trip through the
whorehouse of uglix as well.

OTOH, there are well known library API's (unlike scripts) for determining NCPUS,
and rpm already "knows" NCPUS portably using those library API's. SO the eventual
fix will be devising a better paradigm for configuring rpmbuild than "make -j$NCPUS"
and just rip out all of this hysterical baggage.

Meanwhile the patch is perfect for now, hurts nothing, will be in rpm-5.4.14. Thanks!

[Tim Mooney (tim-mooney)]

I like the idea of RPM being able to use an API to detect how many CPUs are available on the client machine. As a sysadmin, I would like the ability to override whatever it chooses as a default, but having it get it on the client, rather than on whatever system RPM was built upon, is definitely a better solution.

In other news, I should have an email to the rpm-devel mailing list yet today with status info on my devel box setup.