Dne 25.1.2012 00:52, Rex Dieter napsal(a):
Mo Morsi wrote:
On 01/24/2012 04:50 AM, Bohuslav Kabrda wrote:
Hi, since we finally got our Ruby 1.9.3 feature page [1] approved, we are starting rebuild for Ruby 1.9.3. Everyone who owns a package that depends on Ruby or Rubygems should rebuild it in the special Koji target "f17-ruby". This target will be merged into rawhide just before the branching, which will occur on 2012-02-07. After this deadline, you will need to go through the standard Bodhi update process. The detailed instructions on rebuilding the packages, including our suggested changes can be found in [2]. Feel free to contact me or Vit Ondruch (vondruch at redhat dot com) or write to ruby-sig mailing lists, if you run into any kind of problems.
I'm somewhat confused. Has the issue w/ sudo gem install been resolved?
Any citation or bug references for this problem you mention?
-- rex
Let me clear the situation. First of all, this is not issue of "sudo gem install". That command works just fine. That is issue with Bundler. Unfortunately, Bundler is one big hack above RubyGems based on some assumptions which are not true. It can be seen on its code where is a lot of custom logic for specific version o RubyGems and Bundler has a lot more quirks with regard of its usage on package driven systems. It can break for example with every upstream change of RubyGems. Now what is the issue:
Ruby, speaking about upstream as well as 1.8 in Fedora, traditionally broke the FHS. We tried to remove this breakage with Ruby 1.9. RubyGems traditionally installs their binary extensions into the same place as their platform independent code, incompatible with FHS. To be somehow compatible with FHS, this was changed and for Ruby 1.8, the binary extensions were installed into ruby_sitedir. That results in conflicting binary RPMs which conflicts among their versions, although this was never the case for RubyGems packages. So for Ruby 1.9.3 we tried to work on this issue and we modified RubyGems to be able to load the libraries, where the noarch part is placed in share and the binary library in lib, so RPM packaged gems are installed into /usr/share and their binary libraries into /usr/lib. Moreover, we changed how RubyGems works, e.g. by default, "gem install" installs gems into your home directory, so you don't need sudo to work with gems anymore. However, if your are using "gem install" with root users, they are installed into /usr/local/share and their binary libraries are installed into /usr/local/lib.
Now there comes Bundler. Assuming it knows everything about RubyGems, they put together their custom logic how to populate Ruby's load paths, which does not work well with changes we made into RubyGems, i.e. it cannot add the binary extension path to the Ruby's load path, resulting in failure when loading the gem. Nevertheless, this is going to be handled in RPM packaged Bundler and it will work properly as long as user uses RPM packaged Bundler. Once somebody installs upstream version of Bundler, the Bundler fails naturally.
So there are probably 4 solutions to this issue:
1) Always use Bundler provided by Fedora which will works as it should. 2) Force Ruby and RubyGems upstream to properly support FHS. I already provided patches [1] but I need your support. 3) Revert the customized behavior of RubyGems and break FHS. 4) Treat root as regular user and install gem also into root's home directory, but it obviously doesn't make sense.
So obviously I have chosen 1) and trying to move forward with 2). That works most of the times. It breaks only in situation, when you install upstream Bundler using "sudo gem install" and later you want to use some system wide gem with binary extension. If you install gems using "gem install" into your home dir (preferred, default way), it works every time. Mixing of RPMs with other package managers has its limits and this is one of them.
Vit
On 01/25/2012 03:40 AM, Vít Ondruch wrote:
Dne 25.1.2012 00:52, Rex Dieter napsal(a):
Mo Morsi wrote:
On 01/24/2012 04:50 AM, Bohuslav Kabrda wrote:
Hi, since we finally got our Ruby 1.9.3 feature page [1] approved, we are starting rebuild for Ruby 1.9.3. Everyone who owns a package that depends on Ruby or Rubygems should rebuild it in the special Koji target "f17-ruby". This target will be merged into rawhide just before the branching, which will occur on 2012-02-07. After this deadline, you will need to go through the standard Bodhi update process. The detailed instructions on rebuilding the packages, including our suggested changes can be found in [2]. Feel free to contact me or Vit Ondruch (vondruch at redhat dot com) or write to ruby-sig mailing lists, if you run into any kind of problems.
I'm somewhat confused. Has the issue w/ sudo gem install been resolved?
Any citation or bug references for this problem you mention?
-- rex
Let me clear the situation. First of all, this is not issue of "sudo gem install". That command works just fine. That is issue with Bundler. Unfortunately, Bundler is one big hack above RubyGems based on some assumptions which are not true. It can be seen on its code where is a lot of custom logic for specific version o RubyGems and Bundler has a lot more quirks with regard of its usage on package driven systems. It can break for example with every upstream change of RubyGems. Now what is the issue:
Ruby, speaking about upstream as well as 1.8 in Fedora, traditionally broke the FHS. We tried to remove this breakage with Ruby 1.9. RubyGems traditionally installs their binary extensions into the same place as their platform independent code, incompatible with FHS. To be somehow compatible with FHS, this was changed and for Ruby 1.8, the binary extensions were installed into ruby_sitedir. That results in conflicting binary RPMs which conflicts among their versions, although this was never the case for RubyGems packages. So for Ruby 1.9.3 we tried to work on this issue and we modified RubyGems to be able to load the libraries, where the noarch part is placed in share and the binary library in lib, so RPM packaged gems are installed into /usr/share and their binary libraries into /usr/lib. Moreover, we changed how RubyGems works, e.g. by default, "gem install" installs gems into your home directory, so you don't need sudo to work with gems anymore. However, if your are using "gem install" with root users, they are installed into /usr/local/share and their binary libraries are installed into /usr/local/lib.
Now there comes Bundler. Assuming it knows everything about RubyGems, they put together their custom logic how to populate Ruby's load paths, which does not work well with changes we made into RubyGems, i.e. it cannot add the binary extension path to the Ruby's load path, resulting in failure when loading the gem. Nevertheless, this is going to be handled in RPM packaged Bundler and it will work properly as long as user uses RPM packaged Bundler. Once somebody installs upstream version of Bundler, the Bundler fails naturally.
So there are probably 4 solutions to this issue:
- Always use Bundler provided by Fedora which will works as it should.
- Force Ruby and RubyGems upstream to properly support FHS. I already
provided patches [1] but I need your support. 3) Revert the customized behavior of RubyGems and break FHS. 4) Treat root as regular user and install gem also into root's home directory, but it obviously doesn't make sense.
So obviously I have chosen 1) and trying to move forward with 2). That works most of the times. It breaks only in situation, when you install upstream Bundler using "sudo gem install" and later you want to use some system wide gem with binary extension. If you install gems using "gem install" into your home dir (preferred, default way), it works every time. Mixing of RPMs with other package managers has its limits and this is one of them.
OK so the only thing that will not work after everything is said and done is running 'sudo bundle install' if you've installed bunder via 'gem install bundler' and not 'yum install rubygem-bundler' correct?
If that is the case, I can live with this as running 'bundle install' as sudo is discouraged upstream anyways. I've seen a few cases which this is used as a hacky workaround, but I think the intention on bundler is to vendorize dependencies locally and is not meant for system-wide management.
My only concern is that upstream practices will change yet again in a manner which our reworking of the load paths to conform to the FHS will be incompatible. Try as we might, I don't believe the Fedora ruby community has enough sway with the upstream ruby community to change their practices (yet) so I'm willing to go forward with this new direction provided that if it becomes incompatible w/ a widespread upstream practice down the road, we evaluate the situation and possibly make the necessary changes to play well w/ the Ruby community. At least until the day we can reasonably influence the direction of the upstream practices.
-Mo
On 01/25/2012 03:40 AM, Vít Ondruch wrote:
Dne 25.1.2012 00:52, Rex Dieter napsal(a):
Mo Morsi wrote:
On 01/24/2012 04:50 AM, Bohuslav Kabrda wrote:
Hi, since we finally got our Ruby 1.9.3 feature page [1] approved, we are starting rebuild for Ruby 1.9.3. Everyone who owns a package that depends on Ruby or Rubygems should rebuild it in the special Koji target "f17-ruby". This target will be merged into rawhide just before the branching, which will occur on 2012-02-07. After this deadline, you will need to go through the standard Bodhi update process. The detailed instructions on rebuilding the packages, including our suggested changes can be found in [2]. Feel free to contact me or Vit Ondruch (vondruch at redhat dot com) or write to ruby-sig mailing lists, if you run into any kind of problems.
I'm somewhat confused. Has the issue w/ sudo gem install been resolved?
Any citation or bug references for this problem you mention?
-- rex
Let me clear the situation. First of all, this is not issue of "sudo gem install". That command works just fine. That is issue with Bundler. Unfortunately, Bundler is one big hack above RubyGems based on some assumptions which are not true. It can be seen on its code where is a lot of custom logic for specific version o RubyGems and Bundler has a lot more quirks with regard of its usage on package driven systems. It can break for example with every upstream change of RubyGems. Now what is the issue:
Ruby, speaking about upstream as well as 1.8 in Fedora, traditionally broke the FHS. We tried to remove this breakage with Ruby 1.9. RubyGems traditionally installs their binary extensions into the same place as their platform independent code, incompatible with FHS. To be somehow compatible with FHS, this was changed and for Ruby 1.8, the binary extensions were installed into ruby_sitedir. That results in conflicting binary RPMs which conflicts among their versions, although this was never the case for RubyGems packages. So for Ruby 1.9.3 we tried to work on this issue and we modified RubyGems to be able to load the libraries, where the noarch part is placed in share and the binary library in lib, so RPM packaged gems are installed into /usr/share and their binary libraries into /usr/lib. Moreover, we changed how RubyGems works, e.g. by default, "gem install" installs gems into your home directory, so you don't need sudo to work with gems anymore. However, if your are using "gem install" with root users, they are installed into /usr/local/share and their binary libraries are installed into /usr/local/lib.
Now there comes Bundler. Assuming it knows everything about RubyGems, they put together their custom logic how to populate Ruby's load paths, which does not work well with changes we made into RubyGems, i.e. it cannot add the binary extension path to the Ruby's load path, resulting in failure when loading the gem. Nevertheless, this is going to be handled in RPM packaged Bundler and it will work properly as long as user uses RPM packaged Bundler. Once somebody installs upstream version of Bundler, the Bundler fails naturally.
So there are probably 4 solutions to this issue:
- Always use Bundler provided by Fedora which will works as it
should. 2) Force Ruby and RubyGems upstream to properly support FHS. I already provided patches [1] but I need your support. 3) Revert the customized behavior of RubyGems and break FHS. 4) Treat root as regular user and install gem also into root's home directory, but it obviously doesn't make sense.
So obviously I have chosen 1) and trying to move forward with 2). That works most of the times. It breaks only in situation, when you install upstream Bundler using "sudo gem install" and later you want to use some system wide gem with binary extension. If you install gems using "gem install" into your home dir (preferred, default way), it works every time. Mixing of RPMs with other package managers has its limits and this is one of them.
OK so the only thing that will not work after everything is said and done is running 'sudo bundle install' if you've installed bunder via 'gem install bundler' and not 'yum install rubygem-bundler' correct?
Exactly.
If that is the case, I can live with this as running 'bundle install' as sudo is discouraged upstream anyways. I've seen a few cases which this is used as a hacky workaround, but I think the intention on bundler is to vendorize dependencies locally and is not meant for system-wide management.
My only concern is that upstream practices will change yet again in a manner which our reworking of the load paths to conform to the FHS will be incompatible. Try as we might, I don't believe the Fedora ruby community has enough sway with the upstream ruby community to change their practices (yet) so I'm willing to go forward with this new direction provided that if it becomes incompatible w/ a widespread upstream practice down the road, we evaluate the situation and possibly make the necessary changes to play well w/ the Ruby community. At least until the day we can reasonably influence the direction of the upstream practices.
-Mo
Yes, we may not have enough influence, but we should not stop trying :)
Regards, Slavek.
Dne 25.1.2012 22:46, Mo Morsi napsal(a):
On 01/25/2012 03:40 AM, Vít Ondruch wrote:
Dne 25.1.2012 00:52, Rex Dieter napsal(a):
Mo Morsi wrote:
On 01/24/2012 04:50 AM, Bohuslav Kabrda wrote:
Hi, since we finally got our Ruby 1.9.3 feature page [1] approved, we are starting rebuild for Ruby 1.9.3. Everyone who owns a package that depends on Ruby or Rubygems should rebuild it in the special Koji target "f17-ruby". This target will be merged into rawhide just before the branching, which will occur on 2012-02-07. After this deadline, you will need to go through the standard Bodhi update process. The detailed instructions on rebuilding the packages, including our suggested changes can be found in [2]. Feel free to contact me or Vit Ondruch (vondruch at redhat dot com) or write to ruby-sig mailing lists, if you run into any kind of problems.
I'm somewhat confused. Has the issue w/ sudo gem install been resolved?
Any citation or bug references for this problem you mention?
-- rex
Let me clear the situation. First of all, this is not issue of "sudo gem install". That command works just fine. That is issue with Bundler. Unfortunately, Bundler is one big hack above RubyGems based on some assumptions which are not true. It can be seen on its code where is a lot of custom logic for specific version o RubyGems and Bundler has a lot more quirks with regard of its usage on package driven systems. It can break for example with every upstream change of RubyGems. Now what is the issue:
Ruby, speaking about upstream as well as 1.8 in Fedora, traditionally broke the FHS. We tried to remove this breakage with Ruby 1.9. RubyGems traditionally installs their binary extensions into the same place as their platform independent code, incompatible with FHS. To be somehow compatible with FHS, this was changed and for Ruby 1.8, the binary extensions were installed into ruby_sitedir. That results in conflicting binary RPMs which conflicts among their versions, although this was never the case for RubyGems packages. So for Ruby 1.9.3 we tried to work on this issue and we modified RubyGems to be able to load the libraries, where the noarch part is placed in share and the binary library in lib, so RPM packaged gems are installed into /usr/share and their binary libraries into /usr/lib. Moreover, we changed how RubyGems works, e.g. by default, "gem install" installs gems into your home directory, so you don't need sudo to work with gems anymore. However, if your are using "gem install" with root users, they are installed into /usr/local/share and their binary libraries are installed into /usr/local/lib.
Now there comes Bundler. Assuming it knows everything about RubyGems, they put together their custom logic how to populate Ruby's load paths, which does not work well with changes we made into RubyGems, i.e. it cannot add the binary extension path to the Ruby's load path, resulting in failure when loading the gem. Nevertheless, this is going to be handled in RPM packaged Bundler and it will work properly as long as user uses RPM packaged Bundler. Once somebody installs upstream version of Bundler, the Bundler fails naturally.
So there are probably 4 solutions to this issue:
- Always use Bundler provided by Fedora which will works as it should.
- Force Ruby and RubyGems upstream to properly support FHS. I
already provided patches [1] but I need your support. 3) Revert the customized behavior of RubyGems and break FHS. 4) Treat root as regular user and install gem also into root's home directory, but it obviously doesn't make sense.
So obviously I have chosen 1) and trying to move forward with 2). That works most of the times. It breaks only in situation, when you install upstream Bundler using "sudo gem install" and later you want to use some system wide gem with binary extension. If you install gems using "gem install" into your home dir (preferred, default way), it works every time. Mixing of RPMs with other package managers has its limits and this is one of them.
OK so the only thing that will not work after everything is said and done is running 'sudo bundle install' if you've installed bunder via 'gem install bundler' and not 'yum install rubygem-bundler' correct?
If that is the case, I can live with this as running 'bundle install' as sudo is discouraged upstream anyways. I've seen a few cases which this is used as a hacky workaround, but I think the intention on bundler is to vendorize dependencies locally and is not meant for system-wide management.
My only concern is that upstream practices will change yet again in a manner which our reworking of the load paths to conform to the FHS will be incompatible. Try as we might, I don't believe the Fedora ruby community has enough sway with the upstream ruby community to change their practices (yet) so I'm willing to go forward with this new direction provided that if it becomes incompatible w/ a widespread upstream practice down the road, we evaluate the situation and possibly make the necessary changes to play well w/ the Ruby community. At least until the day we can reasonably influence the direction of the upstream practices.
-Mo
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Nicely summarized.
BTW Red Hat already employs one of ruby-core commiters, so who knows ;)
Vit
ruby-sig@lists.fedoraproject.org
-
Bohuslav Kabrda -
Mo Morsi -
Vít Ondruch