Drop noarch and set debug_package to nil rubygem-sassc

[pcreech]

In other build environments, setting 'BuildArch: noarch' causes a build issue where rubygem-ffi can't locate libsass.so.1 in the libraary path, resulting in the following errors:

/usr/share/gems/gems/ffi-1.16.3/lib/ffi/dynamic_library.rb:65:in `load_library': Could not open library '/ext/libsass.so.1': /ext/libsass.so.1: cannot open shared object file: No such file or directory. (LoadError)
Searched in <system library path>, /usr/lib, /usr/local/lib, /opt/local/lib

/usr/share/gems/gems/ffi-1.16.3/lib/ffi/dynamic_library.rb:65:in `load_library': Could not open library '/usr/lib/libsass.so.1': /usr/lib/libsass.so.1: cannot open shared object file: No such file or directory. (LoadError)
Searched in <system library path>, /usr/lib, /usr/local/lib, /opt/local/lib

Once past this issue, the build fails out on debugsources.list being empty. setting debug_packge to nil bypasses this issue.

[pcreech]

@evgeni @ekohl this should address the issues we're seeing in other build systems trying to bring this package's updates to use llibsass.so.1

very interested in your thoughts

[evgeni]

So I had a look at the two involved build systems, and found the difference. When building a noarch package on copr, I see:

+ sed -i 's!__dir__!"/usr/lib64"!' lib/sassc/native.rb

while on Patrick's system, I see:

+ sed -i 's!__dir__!"/usr/lib"!' lib/sassc/native.rb

that means the two systems resolve the %_libdir macro differently when building a noarch package

foreman-packaging/packages/foreman/rubygem-sassc/rubygem-sassc.spec

Line 47 in ef2ef58

sed -i "s!__dir__!\"%{_libdir}\"!" lib/sassc/native.rb

Now, honestly, I think the use of _libdir here is wrong, as we need the libdir of the "target" system, not the "build" system, and those can differ (when building noarch).

I see two possibilities:

• hardcode /usr/lib64
• make the package arch-specific again

both are hacks, I don't like both too much, but I think that making the pkg arch-specific is "more" correct, as otherwise we could end up with a s390x system building that package (which is totally allowed) and failing as there we do not ship a libsass.so at all.

[pcreech]

I'd throw my hat in the ring for the second option (that's already enacted on this pr). I'd rather not hardcode a libdir, and that task in and of itself implies that the package really isn't 'noarch', so no need to actually set noarch directly.

Based on that, sounds like this pr is generally g2g if we decide on option 2?

[evgeni]

I'm fine with this PR, but would love to have a second pair of eyes (@ekohl) on this, as it tends to be a pain in the ass (noarch).

[ekohl]

I think this is the less ugly hack because it'll work correctly once we start building on other arches. And since the lib path is arch-specific, arguably this package is also arch-specific.