Fedora 28 support

[drzaeus77]

This PR contains a series of fixes to enable a working fedora28 build.
patches 1-3: python3 compat fixes
patch 4: shared-only cmake option
patch 5: rpm packaging updates

[drzaeus77]

@wcohen would it be possible to get your opinion on the content of these changes? I'm not quite an expert yet in building compatible spec files.

[wcohen]

Hi,

As some sanity check I took the srpm from the git repo and did some
koji scratch builds on Fedora 28 and Fedora Rawhide to see if there
were problems with things like missing dependencies or issues with the
non-x86_64 builds.

$ koji build --scratch rawhide ./bcc-0.6.0-34.git.6a6dc30.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=28141383

$ koji build --scratch f28 ./bcc-0.6.0-34.git.6a6dc30.src.rpm
https://koji.fedoraproject.org/koji/taskinfo?taskID=28141438

The existing srpm built fine.

Also built the bcc package locally and ran rpmlint on the result.
There were a couple errors noted and the man pages could be gzip'ed.

$ rpmlint *.rpm|grep E:
bcc.src: E: specfile-error warning: bogus date in %changelog: Thu Jun 13 2018 Brenden Blanco [email protected] - 0.5.0-1
bcc-tools.x86_64: E: arch-dependent-file-in-usr-share /usr/share/bcc/introspection/bps

Lots of warning aboug manpages not being compressed like:
bcc-tools.x86_64: W: manpage-not-compressed gz /usr/share/bcc/man/man8/argdist.8
bcc-tools.x86_64: W: manpage-not-compressed gz /usr/share/bcc/man/man8/bashreadline.8

The bcc.spec should default to building python3-bcc by default rather than python2-bcc.
The "Python Version Support" section of
https://fedoraproject.org/wiki/Packaging:Python#Python_Version_Support
says:

If a piece of software supports python3, it MUST be packaged for python3.

The following sentences says:

If it supports python2 as well, it MAY be packaged for python2.

So it looks like the rpm should produce both python2-bcc AND
python3-bcc. It is possible that people write their own bcc type
tools python2, so those supporting pyton libraries should be there
even if the bcc-tools rpm are python3 based.

For determining whether to build python3 version of things could use the
Fedora version. Something like the following from systemtap.spec:

%{!?with_python3: %global with_python3 0%{?fedora} >= 23 || 0%{?rhel} > 7}

python_spec.txt

Static linking of Fedora packages is discouraged as mentioned in
https://fedoraproject.org/wiki/Packaging:Guidelines#Statically_Linking_Executables
would it be possible to use the llvm shared libraries by default?

Why the need for local_clang_static? Is the rpm alway building with the llvm code?
Isn't the only question is whether the executables are statically or dynamically linked?

[drzaeus77]

@wcohen Thanks for the thorough review.
I've fixed the easy rpmlint error, but I'll ask the introspection tool author to consider relocating that tool in a separate PR (@iamkafai).

Lots of warning aboug manpages not being compressed

Added a compression step during manpage installation. This will affect all targets.

So it looks like the rpm should produce both python2-bcc AND
python3-bcc. It is possible that people write their own bcc type
tools python2, so those supporting pyton libraries should be there
even if the bcc-tools rpm are python3 based.

I believe we are already building both python2/python3. I don't anticipate disabling the python2 package build at any point.

For determining whether to build python3 version of things could use the
Fedora version.

I've done this, for both the with_python3 and with_llvm_shared conditions, albeit with a slightly more complex syntax in order to retain the --with option. The default will be to enable both python3 and dynamic linking in fc28/rhel8 and newer. I prefer to leave the old approach for earlier versions in order to keep the same behavior in packages that have already shipped.

Why the need for local_clang_static? Is the rpm alway building with the llvm code?

At some point in the past, it was not possible to find an llvm package that included bpf support (llvm 3.7.1 and newer), and I didn't want to include a runtime dependency on packages that weren't shipping yet. So, we were building llvm statically in the buildbots and linking against those statically. The situation has since improved, and so it makes sense to depend on the official llvm builds. The local_clang_static option also makes sense if some developers are working on newer unavailable llvm versions, and want to link those in statically. However, we are not doing that in any of our builds and so I would consider this option legacy.

[drzaeus77]

@yonghong-song I think this is ready to merge.

[yonghong-song]

Done. Thanks!