No rest for the wicked… but first, thank you to everybody who has
helped create and get RC1 out.
I'd like to release RC2 by this time next week, so the cut off is about
Thursday. We should be able to complete these tasks by then:
-
Admin login bug on new install (Greg's submitted a PR)
Bug #2519: Admin account not enabled after db:migrate - Foreman
-
Passenger solution for EL6, which should be either:
a) package Passenger 4 to allow multiple Ruby versions, update
puppet-passenger to only use our repo, update vhosts to configure
PassengerRuby.
b) use thin and reverse proxies
c) use passenger-standalone and reverse proxies (#2529, #2530)
My preference is (a) if it does indeed work, followed by (b) after
having witnessed the passenger-standalone packaging.
-
Locale switching not working (Tomas working on it), and also import
the WIP translations from Transifex
Bug #2536: Available locales not populated in production mode - Foreman
-
ruby193-rubygem-mysql{,2} built (Martin working on it)
Nice-to-haves would be:
-
SELinux subpackage added to foreman.spec, policy is already in
foreman-rpms repo
Bug #2517: SELinux should be built as an Foreman subpackage - Foreman
-
Builds for RHEL5, Fedora 17(?), 18 and 32-bit(?)
And of course, anything from our list:
http://projects.theforeman.org/projects/foreman/issues?query_id=23
···
--
Dominic Cleal
Red Hat Engineering
> No rest for the wicked… but first, thank you to everybody who has
> helped create and get RC1 out.
>
> I'd like to release RC2 by this time next week, so the cut off is about
> Thursday. We should be able to complete these tasks by then:
>
> 1. Admin login bug on new install (Greg's submitted a PR)
> Bug #2519: Admin account not enabled after db:migrate - Foreman
>
> 2. Passenger solution for EL6, which should be either:
> a) package Passenger 4 to allow multiple Ruby versions, update
> puppet-passenger to only use our repo, update vhosts to configure
> PassengerRuby.
> b) use thin and reverse proxies
> c) use passenger-standalone and reverse proxies (#2529, #2530)
>
> My preference is (a) if it does indeed work, followed by (b) after
> having witnessed the passenger-standalone packaging.
Can start with (a) on Monday if nobody else is interested
>
> 3. Locale switching not working (Tomas working on it), and also import
> the WIP translations from Transifex
> Bug #2536: Available locales not populated in production mode - Foreman
>
> 4. ruby193-rubygem-mysql{,2} built (Martin working on it)
Done
···
On 05/24/2013 05:17 PM, Dominic Cleal wrote:
>
> Nice-to-haves would be:
>
> 5. SELinux subpackage added to foreman.spec, policy is already in
> foreman-rpms repo
> http://projects.theforeman.org/issues/2517
>
> 6. Builds for RHEL5, Fedora 17(?), 18 and 32-bit(?)
>
> And of course, anything from our list:
> http://projects.theforeman.org/projects/foreman/issues?query_id=23
>
I've copied these onto an etherpad on Lukas' suggestion, so we can keep
the current status up to date:
http://etherpad-domcleal.rhcloud.com/p/Foreman1.2Packaging
···
On 24/05/13 16:17, Dominic Cleal wrote:
> No rest for the wicked... but first, thank you to everybody who has
> helped create and get RC1 out.
>
> I'd like to release RC2 by this time next week, so the cut off is about
> Thursday. We should be able to complete these tasks by then:
–
Dominic Cleal
Red Hat Engineering
>> 2. Passenger solution for EL6, which should be either:
>> a) package Passenger 4 to allow multiple Ruby versions, update
>> puppet-passenger to only use our repo, update vhosts to configure
>> PassengerRuby.
>> b) use thin and reverse proxies
>> c) use passenger-standalone and reverse proxies (#2529, #2530)
>>
>> My preference is (a) if it does indeed work, followed by (b) after
>> having witnessed the passenger-standalone packaging.
> Can start with (a) on Monday if nobody else is interested
Dmitri had offered too, but he's getting tied up with
community-templates stuff I think. It'd be good to make a start on this
ASAP to check it's feasible.
I'm most worried about backporting the patches that the Fedora spec file
applies to Passenger 3.0. A couple (like spawn-ip) we can remove as
they're features, but others might need more work to be rebased for
Passenger 4.
>> 3. Locale switching not working (Tomas working on it), and also import
>> the WIP translations from Transifex
>> Bug #2536: Available locales not populated in production mode - Foreman
>>
>> 4. ruby193-rubygem-mysql{,2} built (Martin working on it)
> Done
Great, thanks. Those will get included in RC2 then.
···
On 24/05/13 16:35, Martin Bačovský wrote:
> On 05/24/2013 05:17 PM, Dominic Cleal wrote:
–
Dominic Cleal
Red Hat Engineering
I set up Passenger 4 today from source to make sure it will actually
work as the docs suggest it does, and my test was successful. It ran
Foreman under the ruby193 environment and Puppet under the system 1.8.7
Ruby.
There seem to be three core bits of Passenger:
- ruby code, installed as a rubygem in the case of the rubygem-passenger
RPM and referenced in PassengerRoot (Apache config)
- compiled Apache module in mod_passenger subpackage
- native ruby code, in rubygem-passenger-native-libs subpackage
I think we could continue building rubygem-passenger against the system
Ruby, which naturally provides us with the native-libs subpackage for
the Puppet vhost that's using the system Ruby. We just then need a
build of native-libs (which is just a .so in the Ruby load path) built
under the SCL Ruby, no other SCL-specific packages are needed.
If we used the same source package and simply rebuilt it for SCL, we
could take rubygem-passenger, mod_passenger
rubygem-passenger-native-libs etc. from the system Ruby build, then take
only ruby193-rubygem-passenger-native-libs from the SCL build using the
comps file when the repos are built. A possible hitch is we might need
to add an SCL prefix to "mod_passenger" so we don't have two in the
build tag?
Else we create a new independent SCL-enabled package and use
rubygem-passenger-devel as a BuildRequires, or the original Passenger
tarball, then run "ruby193-rake native_support" from the top level
Passenger directory. This creates
libout/ruby/ruby-1.9.3-x86_64-linux/passenger_native_support.so, which
can be packaged into /opt/rh/ruby193/root/usr/lib64/ruby/vendor_ruby/ or
similar. This might be quicker than SCL-enabling the entire
rubygem-passenger RPM (which needs rebasing anyway from 3->4).
There's a bit of installer work we need to do next:
a) install the new ruby193 passenger package too (new class in
puppet-passenger, include based on OS?)
b) add PassengerRuby /usr/bin/ruby193-ruby to Apache's foreman.conf,
based on the OS(?)
c) remove {Rails,Rack}AutoDetect from foreman.conf and puppet.conf (I'm
not sure these are needed at the moment anyway.)
···
On 24/05/13 17:19, Dominic Cleal wrote:
> On 24/05/13 16:35, Martin Bačovský wrote:
>> On 05/24/2013 05:17 PM, Dominic Cleal wrote:
>>> 2. Passenger solution for EL6, which should be either:
>>> a) package Passenger 4 to allow multiple Ruby versions, update
>>> puppet-passenger to only use our repo, update vhosts to configure
>>> PassengerRuby.
>>> b) use thin and reverse proxies
>>> c) use passenger-standalone and reverse proxies (#2529, #2530)
>>>
>>> My preference is (a) if it does indeed work, followed by (b) after
>>> having witnessed the passenger-standalone packaging.
>> Can start with (a) on Monday if nobody else is interested
>
> Dmitri had offered too, but he's getting tied up with
> community-templates stuff I think. It'd be good to make a start on this
> ASAP to check it's feasible.
>
> I'm most worried about backporting the patches that the Fedora spec file
> applies to Passenger 3.0. A couple (like spawn-ip) we can remove as
> they're features, but others might need more work to be rebased for
> Passenger 4.
–
Dominic Cleal
Red Hat Engineering
>>>> 2. Passenger solution for EL6, which should be either:
>>>> a) package Passenger 4 to allow multiple Ruby versions, update
>>>> puppet-passenger to only use our repo, update vhosts to configure
>>>> PassengerRuby.
>>>> b) use thin and reverse proxies
>>>> c) use passenger-standalone and reverse proxies (#2529, #2530)
>>>>
>>>> My preference is (a) if it does indeed work, followed by (b) after
>>>> having witnessed the passenger-standalone packaging.
>>> Can start with (a) on Monday if nobody else is interested
>> Dmitri had offered too, but he's getting tied up with
>> community-templates stuff I think. It'd be good to make a start on this
>> ASAP to check it's feasible.
>>
>> I'm most worried about backporting the patches that the Fedora spec file
>> applies to Passenger 3.0. A couple (like spawn-ip) we can remove as
>> they're features, but others might need more work to be rebased for
>> Passenger 4.
From what I saw it seems that spawn-ip (the most complex of the
patches) fortunatelly can be omitted the rest seems relatively simple
> I set up Passenger 4 today from source to make sure it will actually
> work as the docs suggest it does, and my test was successful. It ran
> Foreman under the ruby193 environment and Puppet under the system 1.8.7
> Ruby.
That's cool
> There seem to be three core bits of Passenger:
> - ruby code, installed as a rubygem in the case of the rubygem-passenger
> RPM and referenced in PassengerRoot (Apache config)
> - compiled Apache module in mod_passenger subpackage
> - native ruby code, in rubygem-passenger-native-libs subpackage
>
> I think we could continue building rubygem-passenger against the system
> Ruby, which naturally provides us with the native-libs subpackage for
> the Puppet vhost that's using the system Ruby. We just then need a
> build of native-libs (which is just a .so in the Ruby load path) built
> under the SCL Ruby, no other SCL-specific packages are needed.
>
> If we used the same source package and simply rebuilt it for SCL, we
> could take rubygem-passenger, mod_passenger
> rubygem-passenger-native-libs etc. from the system Ruby build, then take
> only ruby193-rubygem-passenger-native-libs from the SCL build using the
> comps file when the repos are built. A possible hitch is we might need
> to add an SCL prefix to "mod_passenger" so we don't have two in the
> build tag?
I would go with same scl enabled spec and build it under both scl and
nonscl tags as we do with other smart-proxy related gems. That way we
would have both ruby193-rubygem-passenger and rubygem-passenger in our
repo. So far it seems that every subpackage but native-libs has to be
prefixed as they have o dependency on prefixed rubygem. native-libs
shouldn't cause conflict in the yum repo as it is set to inherit
packages preferably from the scl tag in case of conflict.
I started with modifications of the spec for passenger 4.0.3 and will
keep you informed.
M
···
On 05/26/2013 01:09 AM, Dominic Cleal wrote:
> On 24/05/13 17:19, Dominic Cleal wrote:
>> On 24/05/13 16:35, Martin Bačovský wrote:
>>> On 05/24/2013 05:17 PM, Dominic Cleal wrote:
Else we create a new independent SCL-enabled package and use
rubygem-passenger-devel as a BuildRequires, or the original Passenger
tarball, then run “ruby193-rake native_support” from the top level
Passenger directory. This creates
libout/ruby/ruby-1.9.3-x86_64-linux/passenger_native_support.so, which
can be packaged into /opt/rh/ruby193/root/usr/lib64/ruby/vendor_ruby/ or
similar. This might be quicker than SCL-enabling the entire
rubygem-passenger RPM (which needs rebasing anyway from 3->4).
There’s a bit of installer work we need to do next:
a) install the new ruby193 passenger package too (new class in
puppet-passenger, include based on OS?)
b) add PassengerRuby /usr/bin/ruby193-ruby to Apache’s foreman.conf,
based on the OS(?)
c) remove {Rails,Rack}AutoDetect from foreman.conf and puppet.conf (I’m
not sure these are needed at the moment anyway.)
>> There seem to be three core bits of Passenger:
>> > - ruby code, installed as a rubygem in the case of the rubygem-passenger
>> > RPM and referenced in PassengerRoot (Apache config)
>> > - compiled Apache module in mod_passenger subpackage
>> > - native ruby code, in rubygem-passenger-native-libs subpackage
>> >
>> > I think we could continue building rubygem-passenger against the system
>> > Ruby, which naturally provides us with the native-libs subpackage for
>> > the Puppet vhost that's using the system Ruby. We just then need a
>> > build of native-libs (which is just a .so in the Ruby load path) built
>> > under the SCL Ruby, no other SCL-specific packages are needed.
>> >
>> > If we used the same source package and simply rebuilt it for SCL, we
>> > could take rubygem-passenger, mod_passenger
>> > rubygem-passenger-native-libs etc. from the system Ruby build, then take
>> > only ruby193-rubygem-passenger-native-libs from the SCL build using the
>> > comps file when the repos are built. A possible hitch is we might need
>> > to add an SCL prefix to "mod_passenger" so we don't have two in the
>> > build tag?
> I would go with same scl enabled spec and build it under both scl and
> nonscl tags as we do with other smart-proxy related gems. That way we
> would have both ruby193-rubygem-passenger and rubygem-passenger in our
> repo. So far it seems that every subpackage but native-libs has to be
> prefixed as they have o dependency on prefixed rubygem. native-libs
> shouldn't cause conflict in the yum repo as it is set to inherit
> packages preferably from the scl tag in case of conflict.
In the final repo we'll need both:
rubygem-passenger-native-libs, for system Ruby
ruby193-rubygem-passenger-native-libs, for ruby193
So native-libs will need prefixing? I see now that native-libs also has
a dependency on the rubygem itself, so we'd also add
ruby193-rubygem-passenger, though I don't think it would get used.
Though if inheritance is set up as you described, I guess we don't need
to prefix mod_passenger unless we want to.
> I started with modifications of the spec for passenger 4.0.3 and will
> keep you informed.
Thanks!
···
On 27/05/13 16:53, Martin Bačovský wrote:
–
Dominic Cleal
Red Hat Engineering
>>> There seem to be three core bits of Passenger:
>>>> - ruby code, installed as a rubygem in the case of the rubygem-passenger
>>>> RPM and referenced in PassengerRoot (Apache config)
>>>> - compiled Apache module in mod_passenger subpackage
>>>> - native ruby code, in rubygem-passenger-native-libs subpackage
>>>>
>>>> I think we could continue building rubygem-passenger against the system
>>>> Ruby, which naturally provides us with the native-libs subpackage for
>>>> the Puppet vhost that's using the system Ruby. We just then need a
>>>> build of native-libs (which is just a .so in the Ruby load path) built
>>>> under the SCL Ruby, no other SCL-specific packages are needed.
>>>>
>>>> If we used the same source package and simply rebuilt it for SCL, we
>>>> could take rubygem-passenger, mod_passenger
>>>> rubygem-passenger-native-libs etc. from the system Ruby build, then take
>>>> only ruby193-rubygem-passenger-native-libs from the SCL build using the
>>>> comps file when the repos are built. A possible hitch is we might need
>>>> to add an SCL prefix to "mod_passenger" so we don't have two in the
>>>> build tag?
>> I would go with same scl enabled spec and build it under both scl and
>> nonscl tags as we do with other smart-proxy related gems. That way we
>> would have both ruby193-rubygem-passenger and rubygem-passenger in our
>> repo. So far it seems that every subpackage but native-libs has to be
>> prefixed as they have o dependency on prefixed rubygem. native-libs
>> shouldn't cause conflict in the yum repo as it is set to inherit
>> packages preferably from the scl tag in case of conflict.
> In the final repo we'll need both:
>
> rubygem-passenger-native-libs, for system Ruby
> ruby193-rubygem-passenger-native-libs, for ruby193
>
> So native-libs will need prefixing? I see now that native-libs also has
> a dependency on the rubygem itself, so we'd also add
> ruby193-rubygem-passenger, though I don't think it would get used.
> Though if inheritance is set up as you described, I guess we don't need
> to prefix mod_passenger unless we want to.
Now I see that I overlooked native-libs depenedency on
rubygem-passenger, so I think we need to prefix native-libs as well.
According my understanding if package depends on prefixed package it
should by prefixed as well. So while rubygem-passenger itself requires
gems from collection it should be prefixed and while all subpackages
require rubygem-passenger they all should be prefixed too.
Does that make sense?
M.
···
On 05/27/2013 06:22 PM, Dominic Cleal wrote:
> On 27/05/13 16:53, Martin Bačovský wrote:
I started with modifications of the spec for passenger 4.0.3 and will
keep you informed.
Thanks!
I'm trying to build rubygem-fastthread (a dep for passenger 4) in
katello koji with no luck.
The gem build does not produce .so file for some reason and rpmbuild
therefore fails. The SPECfile was taken from fedora and extended with
support for SCL. My working version of the spec is here
http://fpaste.org/15943/70045391/.
After some investigation it seems
%define gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
evaluate to: /builddir/.gem/ruby/1.9.1 in F17 and F18 and when building
with scl on rhel6
while on rhel6 (without scl) it evaluates to: /usr/lib64/ruby/gems/1.8
The former case leads to Makefile not being able to produce .so file
Any idea how to fix that?
M
···
On 05/27/2013 07:09 PM, Dominic Cleal wrote:
> On 27/05/13 17:52, Martin Bačovský wrote:
>> On 05/27/2013 06:22 PM, Dominic Cleal wrote:
>>> On 27/05/13 16:53, Martin Bačovský wrote:
>>>>> There seem to be three core bits of Passenger:
>>>>>> - ruby code, installed as a rubygem in the case of the rubygem-passenger
>>>>>> RPM and referenced in PassengerRoot (Apache config)
>>>>>> - compiled Apache module in mod_passenger subpackage
>>>>>> - native ruby code, in rubygem-passenger-native-libs subpackage
>>>>>>
>>>>>> I think we could continue building rubygem-passenger against the system
>>>>>> Ruby, which naturally provides us with the native-libs subpackage for
>>>>>> the Puppet vhost that's using the system Ruby. We just then need a
>>>>>> build of native-libs (which is just a .so in the Ruby load path) built
>>>>>> under the SCL Ruby, no other SCL-specific packages are needed.
>>>>>>
>>>>>> If we used the same source package and simply rebuilt it for SCL, we
>>>>>> could take rubygem-passenger, mod_passenger
>>>>>> rubygem-passenger-native-libs etc. from the system Ruby build, then take
>>>>>> only ruby193-rubygem-passenger-native-libs from the SCL build using the
>>>>>> comps file when the repos are built. A possible hitch is we might need
>>>>>> to add an SCL prefix to "mod_passenger" so we don't have two in the
>>>>>> build tag?
>>>> I would go with same scl enabled spec and build it under both scl and
>>>> nonscl tags as we do with other smart-proxy related gems. That way we
>>>> would have both ruby193-rubygem-passenger and rubygem-passenger in our
>>>> repo. So far it seems that every subpackage but native-libs has to be
>>>> prefixed as they have o dependency on prefixed rubygem. native-libs
>>>> shouldn't cause conflict in the yum repo as it is set to inherit
>>>> packages preferably from the scl tag in case of conflict.
>>> In the final repo we'll need both:
>>>
>>> rubygem-passenger-native-libs, for system Ruby
>>> ruby193-rubygem-passenger-native-libs, for ruby193
>>>
>>> So native-libs will need prefixing? I see now that native-libs also has
>>> a dependency on the rubygem itself, so we'd also add
>>> ruby193-rubygem-passenger, though I don't think it would get used.
>>> Though if inheritance is set up as you described, I guess we don't need
>>> to prefix mod_passenger unless we want to.
>> Now I see that I overlooked native-libs depenedency on
>> rubygem-passenger, so I think we need to prefix native-libs as well.
>>
>> According my understanding if package depends on prefixed package it
>> should by prefixed as well. So while rubygem-passenger itself requires
>> gems from collection it should be prefixed and while all subpackages
>> require rubygem-passenger they all should be prefixed too.
>> Does that make sense?
> Yep, agreed.
>
Sidestepping the build issue for a moment, are you sure this is required?
I see the Fedora pkgs repo says it's a dead package as of Ruby 1.9.3,
the passenger 3 spec file had a patch to remove the dependency and there
are discussions about it being 1.8 only:
http://groups.google.com/group/phusion-passenger/browse_thread/thread/540755649c2a760f/5ee3e27ab195c2cf
https://github.com/mental/fastthread/issues/2
lib/phusion_passenger/dependencies.rb has
Dependencies#fastthread_required? which only returns true on pre-1.8.7.
···
On 01/06/13 01:13, Martin Bačovský wrote:
> On 05/27/2013 07:09 PM, Dominic Cleal wrote:
>> On 27/05/13 17:52, Martin Bačovský wrote:
>>> On 05/27/2013 06:22 PM, Dominic Cleal wrote:
>>>> On 27/05/13 16:53, Martin Bačovský wrote:
>>>>>> There seem to be three core bits of Passenger:
>>>>>>> - ruby code, installed as a rubygem in the case of the rubygem-passenger
>>>>>>> RPM and referenced in PassengerRoot (Apache config)
>>>>>>> - compiled Apache module in mod_passenger subpackage
>>>>>>> - native ruby code, in rubygem-passenger-native-libs subpackage
>>>>>>>
>>>>>>> I think we could continue building rubygem-passenger against the system
>>>>>>> Ruby, which naturally provides us with the native-libs subpackage for
>>>>>>> the Puppet vhost that's using the system Ruby. We just then need a
>>>>>>> build of native-libs (which is just a .so in the Ruby load path) built
>>>>>>> under the SCL Ruby, no other SCL-specific packages are needed.
>>>>>>>
>>>>>>> If we used the same source package and simply rebuilt it for SCL, we
>>>>>>> could take rubygem-passenger, mod_passenger
>>>>>>> rubygem-passenger-native-libs etc. from the system Ruby build, then take
>>>>>>> only ruby193-rubygem-passenger-native-libs from the SCL build using the
>>>>>>> comps file when the repos are built. A possible hitch is we might need
>>>>>>> to add an SCL prefix to "mod_passenger" so we don't have two in the
>>>>>>> build tag?
>>>>> I would go with same scl enabled spec and build it under both scl and
>>>>> nonscl tags as we do with other smart-proxy related gems. That way we
>>>>> would have both ruby193-rubygem-passenger and rubygem-passenger in our
>>>>> repo. So far it seems that every subpackage but native-libs has to be
>>>>> prefixed as they have o dependency on prefixed rubygem. native-libs
>>>>> shouldn't cause conflict in the yum repo as it is set to inherit
>>>>> packages preferably from the scl tag in case of conflict.
>>>> In the final repo we'll need both:
>>>>
>>>> rubygem-passenger-native-libs, for system Ruby
>>>> ruby193-rubygem-passenger-native-libs, for ruby193
>>>>
>>>> So native-libs will need prefixing? I see now that native-libs also has
>>>> a dependency on the rubygem itself, so we'd also add
>>>> ruby193-rubygem-passenger, though I don't think it would get used.
>>>> Though if inheritance is set up as you described, I guess we don't need
>>>> to prefix mod_passenger unless we want to.
>>> Now I see that I overlooked native-libs depenedency on
>>> rubygem-passenger, so I think we need to prefix native-libs as well.
>>>
>>> According my understanding if package depends on prefixed package it
>>> should by prefixed as well. So while rubygem-passenger itself requires
>>> gems from collection it should be prefixed and while all subpackages
>>> require rubygem-passenger they all should be prefixed too.
>>> Does that make sense?
>> Yep, agreed.
>>
> I'm trying to build rubygem-fastthread (a dep for passenger 4) in
> katello koji with no luck.
–
Dominic Cleal
Red Hat Engineering
Ahh, now I see, you are right, I overlooked the patch. Thanks a lot!
···
On 06/01/2013 01:32 PM, Dominic Cleal wrote:
> On 01/06/13 01:13, Martin Bačovský wrote:
>> On 05/27/2013 07:09 PM, Dominic Cleal wrote:
>>> On 27/05/13 17:52, Martin Bačovský wrote:
>>>> On 05/27/2013 06:22 PM, Dominic Cleal wrote:
>>>>> On 27/05/13 16:53, Martin Bačovský wrote:
>>>>>>> There seem to be three core bits of Passenger:
>>>>>>>> - ruby code, installed as a rubygem in the case of the rubygem-passenger
>>>>>>>> RPM and referenced in PassengerRoot (Apache config)
>>>>>>>> - compiled Apache module in mod_passenger subpackage
>>>>>>>> - native ruby code, in rubygem-passenger-native-libs subpackage
>>>>>>>>
>>>>>>>> I think we could continue building rubygem-passenger against the system
>>>>>>>> Ruby, which naturally provides us with the native-libs subpackage for
>>>>>>>> the Puppet vhost that's using the system Ruby. We just then need a
>>>>>>>> build of native-libs (which is just a .so in the Ruby load path) built
>>>>>>>> under the SCL Ruby, no other SCL-specific packages are needed.
>>>>>>>>
>>>>>>>> If we used the same source package and simply rebuilt it for SCL, we
>>>>>>>> could take rubygem-passenger, mod_passenger
>>>>>>>> rubygem-passenger-native-libs etc. from the system Ruby build, then take
>>>>>>>> only ruby193-rubygem-passenger-native-libs from the SCL build using the
>>>>>>>> comps file when the repos are built. A possible hitch is we might need
>>>>>>>> to add an SCL prefix to "mod_passenger" so we don't have two in the
>>>>>>>> build tag?
>>>>>> I would go with same scl enabled spec and build it under both scl and
>>>>>> nonscl tags as we do with other smart-proxy related gems. That way we
>>>>>> would have both ruby193-rubygem-passenger and rubygem-passenger in our
>>>>>> repo. So far it seems that every subpackage but native-libs has to be
>>>>>> prefixed as they have o dependency on prefixed rubygem. native-libs
>>>>>> shouldn't cause conflict in the yum repo as it is set to inherit
>>>>>> packages preferably from the scl tag in case of conflict.
>>>>> In the final repo we'll need both:
>>>>>
>>>>> rubygem-passenger-native-libs, for system Ruby
>>>>> ruby193-rubygem-passenger-native-libs, for ruby193
>>>>>
>>>>> So native-libs will need prefixing? I see now that native-libs also has
>>>>> a dependency on the rubygem itself, so we'd also add
>>>>> ruby193-rubygem-passenger, though I don't think it would get used.
>>>>> Though if inheritance is set up as you described, I guess we don't need
>>>>> to prefix mod_passenger unless we want to.
>>>> Now I see that I overlooked native-libs depenedency on
>>>> rubygem-passenger, so I think we need to prefix native-libs as well.
>>>>
>>>> According my understanding if package depends on prefixed package it
>>>> should by prefixed as well. So while rubygem-passenger itself requires
>>>> gems from collection it should be prefixed and while all subpackages
>>>> require rubygem-passenger they all should be prefixed too.
>>>> Does that make sense?
>>> Yep, agreed.
>>>
>> I'm trying to build rubygem-fastthread (a dep for passenger 4) in
>> katello koji with no luck.
> Sidestepping the build issue for a moment, are you sure this is required?
>
> I see the Fedora pkgs repo says it's a dead package as of Ruby 1.9.3,
> the passenger 3 spec file had a patch to remove the dependency and there
> are discussions about it being 1.8 only:
>
> http://groups.google.com/group/phusion-passenger/browse_thread/thread/540755649c2a760f/5ee3e27ab195c2cf
> http://stackoverflow.com/questions/15076887/failed-to-build-gem-native-extension-ruby-2-0-upgrade-fastthread
> https://github.com/mental/fastthread/issues/2
>
> lib/phusion_passenger/dependencies.rb has
> Dependencies#fastthread_required? which only returns true on pre-1.8.7.
>
