Shibboleth 3 RPM fails to build with FastCGI support

Description

At present, Shibboleth 3.0.2's RPMs can't be built with FastCGI support because of a recent change in the %files section in the spec file.  Previously in 2.6.1 and earlier, the spec file included all build files the libdir with

%{_libdir}/shibboleth/*

which included the shibauthorizer and shibresponder binaries (build into that directory if --with fastcgi was set).  With Shibboleth 3, the %files section has been changed to only include the *.so files in libdir:

`%{_libdir}/shibboleth/*.so

which means that the FastCGI binaries are thus excluded from being packaged.

This causes the following error when building:

 

# rpmbuild --rebuild shibboleth-3.0.2-1.1.src.rpm --with fastcgi [...snip...] Obsoletes: shibboleth-sp-devel = 2.5.0 Processing files: shibboleth-debuginfo-3.0.2-1.1.x86_64 Checking for unpackaged file(s): /usr/lib/rpm/check-files /root/rpmbuild/BUILDROOT/shibboleth-3.0.2-1.1.x86_64 error: Installed (but unpackaged) file(s) found:     /usr/lib64/shibboleth/shibauthorizer    /usr/lib64/shibboleth/shibresponder   RPM build errors:    line 14: prereq is deprecated: PreReq:              xmltooling-schemas(x86-64) >= 3.0.0, opensaml-schemas(x86-64) >= 3.0.0     Installed (but unpackaged) file(s) found:     /usr/lib64/shibboleth/shibauthorizer    /usr/lib64/shibboleth/shibresponder

There's various ways in which this problem could be solved; for example, adding the following lines into the spec file's %files section allow the RPM to be built successfully:

%{?_with_fastcgi:%{_libdir}/shibboleth/shibauthorizer}  %{?_with_fastcgi:%{_libdir}/shibboleth/shibresponder}

 

Environment

CentOS 6.9

Activity

Scott Cantor
October 15, 2018 at 2:58 PM

Fix committed.

Scott Cantor
September 13, 2018 at 2:04 PM

It will be fixed when the next release is done, but I'm not in a position to spend hours on a release for just this. When enough bug reports come in and it's time to do another release this will be included. That could be next year or next month or even next week, it's really impossible to say.

Since none of the current builds include this, I'm not sure why this matters. Anyone doing an SRPM build is in control of the specfile and can easily patch it.

David Beitey
September 13, 2018 at 12:42 AM

Any thoughts on a fix for this issue and/or applying the solution above?  Thanks.

Fixed

Details

Assignee

Reporter

Fix versions

Affects versions

Created August 14, 2018 at 3:32 AM
Updated December 19, 2018 at 4:09 PM
Resolved October 15, 2018 at 2:58 PM