3:50 a.m.
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.
Regards,
Bohuslav "Slavek" Kabrda.
[1] http://fedoraproject.org/wiki/Features/Ruby_1.9.3
[2] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-January/000805.html
5:27 p.m.
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?
That is a blocker as far as adopting the Ruby 1.9.3 RPMs as they stand
for Fedora and needs to be resolved first before making alot of changes
to the master branch / rawhide.
As much as I don't like letting features slip, if we have to wait until
Fedora 18 to get ruby 1.9.3 so be it, we can't ship a solution that
breaks fundamental upstream compatibility.
If we can't figure a solution out by the time Fedora branches, or a
little before it, lets say around the beginning of February, we should
revert the 1.9.3 patch on the master repo until a solution is deduced.
-Mo
5:52 p.m.
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
2:40 a.m.
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
[1] https://github.com/rubygems/rubygems/issues/210
3:15 p.m.
On 01/25/2012 02:10 PM, Vít Ondruch wrote:
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.
FHS is broken by upstream. Fedora ideally should be doing 2) and work
with upstream instead of patching the changes downstream which tends to
cause problems like the current situation.
Rahul
12:51 a.m.
----- Original Message -----
On 01/25/2012 02:10 PM, Vít Ondruch wrote:
> 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.
FHS is broken by upstream. Fedora ideally should be doing 2) and
work
with upstream instead of patching the changes downstream which tends
to
cause problems like the current situation.
Rahul
Yes, we are of course trying to push the patches upstream, but it is a bit problematic,
since the upstream says, that this is an FHS-specific issue and they only want to do
general solutions - see [1] for the discussion.
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://github.com/rubygems/rubygems/issues/210
1:06 p.m.
On 01/27/2012 12:21 PM, Bohuslav Kabrda wrote:
Yes, we are of course trying to push the patches upstream, but it is a bit problematic,
since the upstream says, that this is an FHS-specific issue and they only want to do
general solutions - see [1] for the discussion.
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://github.com/rubygems/rubygems/issues/210
That's not quite what upstream says and I think we can move this forward
if you rope in the ruby maintainers from other major distributions and
get broader support. Meanwhile, using this patch downstream seems
unwarranted since there is no urgent need to fix this.
Rahul
12:56 a.m.
----- Original Message -----
On 01/27/2012 12:21 PM, Bohuslav Kabrda wrote:
>
> Yes, we are of course trying to push the patches upstream, but it
> is a bit problematic, since the upstream says, that this is an
> FHS-specific issue and they only want to do general solutions -
> see [1] for the discussion.
>
> Regards,
> Bohuslav "Slavek" Kabrda.
>
> [1] https://github.com/rubygems/rubygems/issues/210
That's not quite what upstream says and I think we can move this
forward
if you rope in the ruby maintainers from other major distributions
and
get broader support. Meanwhile, using this patch downstream seems
unwarranted since there is no urgent need to fix this.
Rahul
Citing Zenspider [1]:
"Other platforms don't care about FHS and it shouldn't be the default."
So it is what the upstream says and I don't think that packagers from other
distributions would help us. For example, people from Debian/Ubuntu install Gems under
/var/lib/gems [2], which doesn't really make sense to us. What we really need is a
support of Ruby developers, not packagers. We are still working in the issue and
hopefully, we will come up with something that would be acceptable by Rubygems
developers.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://github.com/rubygems/rubygems/issues/210#issuecomment-2624262
[2] https://help.ubuntu.com/community/RubyOnRails#RubyGems_via_apt
2:07 a.m.
On 01/30/2012 07:56 AM, Bohuslav Kabrda wrote:
----- Original Message -----
> On 01/27/2012 12:21 PM, Bohuslav Kabrda wrote:
>
>>
>> Yes, we are of course trying to push the patches upstream, but it
>> is a bit problematic, since the upstream says, that this is an
>> FHS-specific issue and they only want to do general solutions -
>> see [1] for the discussion.
>>
>> Regards,
>> Bohuslav "Slavek" Kabrda.
>>
>> [1] https://github.com/rubygems/rubygems/issues/210
>
> That's not quite what upstream says and I think we can move this
> forward
> if you rope in the ruby maintainers from other major distributions
> and
> get broader support. Meanwhile, using this patch downstream seems
> unwarranted since there is no urgent need to fix this.
>
> Rahul
Citing Zenspider [1]:
"Other platforms don't care about FHS and it shouldn't be the default."
So it is what the upstream says and I don't think that packagers from other
distributions would help us.
This consideration is mostly irrelevant.
We are building the distro, therefore it's our (the packagers') task and
duty to make sure a package technically properly integrates into our
distro. It's upstream's freedom to help us to make integrating their
works into ours easy or to ignore us.
The technical background behind all this is Fedora being a multiarch'ed
distro, into which installing arch-depending binaries into a directory,
which is not supposed to contain arch-dependent files, doesn't fit
_technically_ (Note: This is a technical requirement and not a matter of
conventions).
=> If upstream can't or doesn't want to provide a solution to this
technical problem, Fedora packagers will have to come up with a solution
and carry around patches. This not unusual, because some upstreams' devs
have never used multiarch'ed systems and are not aware about the
shot-comings of their implementation.
For example, people from Debian/Ubuntu install Gems under
/var/lib/gems [2], which doesn't really make sense to us.
Could you elaborate
why you are saying so? I am not sufficiently
familiar with ruby, but it could be a "quick hack" which at least could
help to some extend.
Ralf
2:24 a.m.
----- Original Message -----
On 01/30/2012 07:56 AM, Bohuslav Kabrda wrote:
> ----- Original Message -----
>> On 01/27/2012 12:21 PM, Bohuslav Kabrda wrote:
>>
>>>
>>> Yes, we are of course trying to push the patches upstream, but it
>>> is a bit problematic, since the upstream says, that this is an
>>> FHS-specific issue and they only want to do general solutions -
>>> see [1] for the discussion.
>>>
>>> Regards,
>>> Bohuslav "Slavek" Kabrda.
>>>
>>> [1] https://github.com/rubygems/rubygems/issues/210
>>
>> That's not quite what upstream says and I think we can move this
>> forward
>> if you rope in the ruby maintainers from other major distributions
>> and
>> get broader support. Meanwhile, using this patch downstream seems
>> unwarranted since there is no urgent need to fix this.
>>
>> Rahul
>
> Citing Zenspider [1]:
>
> "Other platforms don't care about FHS and it shouldn't be the
> default." So it is what the upstream says and I don't think that
> packagers from other distributions would help us.
This consideration is mostly irrelevant.
We are building the distro, therefore it's our (the packagers') task
and
duty to make sure a package technically properly integrates into our
distro. It's upstream's freedom to help us to make integrating their
works into ours easy or to ignore us.
The technical background behind all this is Fedora being a
multiarch'ed
distro, into which installing arch-depending binaries into a
directory,
which is not supposed to contain arch-dependent files, doesn't fit
_technically_ (Note: This is a technical requirement and not a matter
of
conventions).
=> If upstream can't or doesn't want to provide a solution to this
technical problem, Fedora packagers will have to come up with a
solution
and carry around patches. This not unusual, because some upstreams'
devs
have never used multiarch'ed systems and are not aware about the
shot-comings of their implementation.
Yes, this is exactly what we are doing - we are carrying the patches that we made so that
we can make things better from Fedora point of view. So what is the problem here? :)
> For example, people from Debian/Ubuntu install Gems under
> /var/lib/gems [2], which doesn't really make sense to us.
Could you elaborate why you are saying so? I am not sufficiently
familiar with ruby, but it could be a "quick hack" which at least
could
help to some extend.
We tend to see rubygems as libraries, that can be shared among systems, not variable data
(as considered by Debian/Ubuntu packagers [1]). Therefore we place them into /usr rather
than into /var according to FHS.
Ralf
--
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] http://www.lucas-nussbaum.net/blog/?p=566
4480
days inactive
4486
days old
9 comments
6 participants
participants (6)
-
Bohuslav Kabrda -
Mo Morsi -
Rahul Sundaram -
Ralf Corsepius -
Rex Dieter -
Vít Ondruch