[apparmor] [patch] fix libapparmor ruby bindings for ruby 2.0

[John Johansen]

On 06/12/2013 03:25 PM, Christian Boltz wrote:
> Hello,
> 
> Am Mittwoch, 12. Juni 2013 schrieb John Johansen:
>> On 06/05/2013 01:23 PM, Christian Boltz wrote:
>>> you might have noticed the discussion about the libapparmor ruby
>>> bindings build failures on openSUSE Factory, which is the first
>>> version with ruby 2.0.
>>>
>>> The problem was that DESTDIR was added to too many variables, which
>>> finally resulted in
> [...]
>> NAK, at least until I understand what is going on better. Specifically
>> from the referenced bug we have
>>
>>   The error message is:
> 
>> *** No rule to make target
>> `/home/abuild/rpmbuild/BUILDROOT/apparmor-2.8.1-147.1.x86_64/usr/incl
>> ude/ruby-2.0.0/ruby.h', needed by `LibAppArmor_wrap.o'.  Stop.
>>
>>   The bug is that it searches for ruby.h _inside the buildroot_, which
>> is obviously wrong.
> 
>     [end of quoting from the bugreport, and sorry for the linebreaks - 
>     KMail doesn't handle quoting of logs very well ;-) ]
> 
> To make things clear: ruby.h is part of the ruby-devel package.
> 
> Also note that the quoted error message is from the openSUSE build 
> service, which means a fresh virtual machine for each build job. 
> (No chroot etc. involved.)
> 
>> But when building packages searching the build root is the correct
>> place to search as you may be building against a different version
>> than your system has installed.
> 
> Well, we have up to 3 places:
> 1) the running system
> 2) a chroot that is used for building (with only the packages needed for 
>    build installed)
> 3) DESTDIR as target for "make install" - in other words: everything 
>    that will end up in the RPM/DEB package
> 
> 1) is needed for obvious reasons ;-)
> 
> 2) is optional, and not too different from 1) - from the compiler's POV, 
> a chroot looks like the running system. The only difference is that with 
> a chroot you can be quite sure not to break your system ;-) and you can 
> control the list of installed packages easier.
> Instead of a chroot (as used by the openSUSE "build" script), you can 
> also setup a virtual machine for each build (as done by the openSUSE 
> build service)
> 
> 3) is highly recommended because otherwise you could easily break your 
> system with make install, and you would never know exactly if you found 
> all files you need to package.
> 
>> Some googling around using
>>   extconf.rb header file ruby.h
>>
>> I find that this error happens usually because of missing the ruby-dev
>> packages
> 
> I have a BuildRequires: ruby-devel of course ;-)
> 
okay thanks

>> My guess is we need to add a dependency on a missing ruby-dev or
>> similar package so that we can pull the ruby.h into the build root.
> 
> It looks like you confuse the build root (2) with DESTDIR (3).
> 
yes

> ruby-devel installs ruby.h in the build root (which can be 1) or 2) - 
> but the (with Ruby 2.0) generated Makefile.rb searches for it inside
> 3) DESTDIR, which is just wrong. (Remember: DESTDIR contains what will 
> end up in the RPM/DEB package.)
> 
okay yes

> 
> The patch fixes this problem, but as I already said, I'm not sure if 
> it's the best way to fix it. I'm not even sure if it's a bug in our 
> extconf.rb, in swig or if mkmf from Ruby 2.0 is buggy ;-)
> 
its not the extconf.rb, it could be swig but it doesn't look like it to
me. It does look like mkmf is generating a bad Makefile.

it shouldn't be used oldincludedir and you are right ruby.h in DESTDIR
is wrong

I'd like to have a day or two more to poke at why its using oldincludedir