Recommended way to install Rubygems

Ruby
21

On Thu, Mar 18, 2010 at 10:21 AM, Lucas N.
[email protected] wrote:

On 18/03/10 at 23:05 +0900, Nick B. wrote:

I was scratching my head wonder why the heck a core piece of ruby like

make me fear that it is unlikely.
Really, sometimes the requirements of keeping the packages in a distro
in-line are at odds with what some users need to do with the software
being packaged.

Not trying to be controversial here, but the discussion could be about
who owns Jerusalem.

The Debian policies are aimed at keeping the overall system under
control moving from one consistent set of package versions to another.

For some people that works well, even for Ruby. But others have the
requirement to treat components in a more flexible way.

For example, we might need to run different versions of gems on the
same machine for different applications. We might run applications
using different versions of Rails, again for example. This is why
gems has the unpack command and why Rails allows gems to be vendored.
The base capability to have multiple versions of gems installed at the
same time is key. Gems which have been converted to (debian) packages
lose this ability, I think.

We might need to run multiple versions of Ruby on the same system,
including 1.8.6, 1.8.7 and 1.9.x If the package maintainer views
1.8.6 and 1.8.7 as the same ‘version’ this is problematical.

Rubyists have developed solutions like ruby switcher and rvm to deal
with this requirement.

If packaged Ruby works for someone, fine. For a long time I’ve been
installing Ruby and rubygems from source on my Debian/Ubuntu systems,
as well as on my OS X machines, in a directory outside of the
territory claimed by the OS, at first manually and now with rvm.

If the packaged version of Ruby is used at all on my machines, it’s
only by other packages which pre-req it, not by code I write.

Also: don’t let the unfriendly tone one often encounters on the internet
get ya down. The medium itself seems to encourage that sort of thing…

That’s not a reason to consider it acceptable.

True enough, OTOH, I’ve found it a lot easier to live on the
inter-tubes if I develop a thick skin, and give everyone the benefit
of the doubt that they are not actively trying to be uncivil, even if
they express themselves in what I might perceive to be an uncivil
fashion.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

22

On 18/03/10 at 23:36 +0900, Brian C. wrote:

Lucas N. wrote:

OpenSSL doesn’t have a lot of fans

Citation Needed

(give me BSD-licensed code any day)

(which is the version of the BSD license that OpenSSL uses. If it was
the 3-clauses BSD license, there would be no problem.)

23

On 18/03/10 at 23:31 +0900, James Edward G. II wrote:

on Debian systems are us explaining to users how to finish their Ruby
install.

In my opinion, the problem is that the Debian maintainers have changed
what it means to install Ruby. That’s not OK to me, because it’s not
their call to make. The Ruby core team gets to decide what it means
to install Ruby.

Apparently, the ruby core team is OK with the current situation, since
apt-get install ruby1.9.1-full/ruby-full is advertised on
Download Ruby. You might want to educate your
users to read the documentation.

Also, I disagree that it’s not our call to make. Most of the software
shipped by Debian is split in seperate packages, and Ruby is the only
case where I hear people complaining about such a minor issue.

(Also note that the split predates me being involved in Ruby
maintenance.)

All of the standard libraries are meant to be
installed so you can count on having them. By changing that decision,
Debian has made it so you can’t count on having them and that changes
the rules of what you can do with Ruby.

If, maybe, the Ruby community fixed the fact that it’s illegal to load
all of stdlib in the same process (because of OpenSSL vs GPL), we could
consider including ssl and readline in the default lib pkg. However, I
don’t
see how we will make Ruby depend on installing Tcl/Tk (because of the TK
bindings), or Emacs (because of the ruby mode for emacs). Note that even
ruby-full doesn’t install the TK and elisp stuff.

24

On 18/03/10 at 23:31 +0900, Austin Z. wrote:

more widely used in the real world than GNU TLS is likely to ever be.
‘openssl’" and “require ‘gnutls’” would satisfy, then I think we’d see
traction. Since this is apparently a problem for people who prefer GNU
TLS, I suggest that it is in their interest to do so.

Note that your lawyer might disagree with you, whether he is a GNU
fanboy or not, because it is widely agreed that the OpenSSL license is
incompatible with the GPL.

I agree that this sucks, but hey, that’s life.

25

On 18/03/10 at 23:45 +0900, Rick DeNatale wrote:

1.8.6 and 1.8.7 as the same ‘version’ this is problematical.

Rubyists have developed solutions like ruby switcher and rvm to deal
with this requirement.

Note there are not many development communities that are proud of the
fact of having different, incompatible versions of the same software
being widely used at the same time.

Most other communities solve that by having more stable APIs and making
sure that their important software supports the latest API.

In Debian Squeeze (next Debian release), we ship (and support for
several years) ruby 1.8 (likely 1.8.249+some backports) and ruby 1.9.1
(maybe a prerelease of 1.9.2, but unlikely). It would be totally insane,
to, additionally, try to support several versions of the same libraries.
Of course, if you want to install many different Ruby and gems versions,
and then try to keep them in a sensible state wrt security issues (which
are not that uncommon in the ruby world), that’s your choice.

Also: don’t let the unfriendly tone one often encounters on the internet
get ya down. The medium itself seems to encourage that sort of thing…

That’s not a reason to consider it acceptable.

True enough, OTOH, I’ve found it a lot easier to live on the
inter-tubes if I develop a thick skin, and give everyone the benefit
of the doubt that they are not actively trying to be uncivil, even if
they express themselves in what I might perceive to be an uncivil
fashion.

It’s really to give the benefit of the doubt about civility to several
people on this list.

26

On Mar 18, 2010, at 10:02 AM, Lucas N. wrote:

does use net/https to communicate, so about 80% of our support issues
Download Ruby. You might want to educate your
users to read the documentation.

I added that to the site recently to help with this issue. :wink: (It was
recommended by another user running into the same problem, so I don’t
think I’m totally alone.)

Also, I disagree that it’s not our call to make. Most of the software
shipped by Debian is split in seperate packages, and Ruby is the only
case where I hear people complaining about such a minor issue.

I find you calling the legitimate complaint that some of us are trying
to explain to you civilly, “such a minor issue,” at least as offensive
as those of our community who have been rude to you. I build Ruby
software for a living and Debian’s packaging does increase our support
issues. Please respect that I have a viable opinion.

All of the standard libraries are meant to be
installed so you can count on having them. By changing that decision,
Debian has made it so you can’t count on having them and that changes
the rules of what you can do with Ruby.

If, maybe, the Ruby community fixed the fact that it’s illegal to load
all of stdlib in the same process (because of OpenSSL vs GPL), we could
consider including ssl and readline in the default lib pkg.

Ruby obviously ships these libraries together without issue. I assume
it’s because the responsibility falls to the user not to load them in
some illegal situation.

I don’t see how that wouldn’t be OK for Debian too. Obviously it is,
since you do offer full install options, right?

Or am I misunderstanding something? (Very possible, as I am not an
expert in these matters.)

James Edward G. II

27

On Mar 18, 2010, at 10:15 AM, Lucas N. wrote:

Note there are not many development communities that are proud of the
fact of having different, incompatible versions of the same software
being widely used at the same time.

Most other communities solve that by having more stable APIs and making
sure that their important software supports the latest API.

Of course, if you want to install many different Ruby and gems versions,
and then try to keep them in a sensible state wrt security issues (which
are not that uncommon in the ruby world), that’s your choice.

You have lost the high ground in the civility argument.

James Edward G. II

28

On 19/03/10 at 00:32 +0900, James Edward G. II wrote:

I completely agree that the split sucks. We run a Ruby service
Apparently, the ruby core team is OK with the current situation,
is the only case where I hear people complaining about such a minor
issue.

I find you calling the legitimate complaint that some of us are trying
to explain to you civilly, “such a minor issue,” at least as offensive
as those of our community who have been rude to you. I build Ruby
software for a living and Debian’s packaging does increase our support
issues. Please respect that I have a viable opinion.

“Such a minor issue” was the split of many software packages into
seperate Debian packages, not the split of Ruby. Sorry if I have
offended you.

Interestingly, we don’t get many complaints on the Debian side about
that. The only place where I hear about it is on this list.

it’s because the responsibility falls to the user not to load them in
some illegal situation.

I don’t see how that wouldn’t be OK for Debian too. Obviously it is,
since you do offer full install options, right?

Or am I misunderstanding something? (Very possible, as I am not an
expert in these matters.)

No, it just seems easier to ship everything in the same binary package
if this doesn’t add a dubious licensing situation (but IANAL).

Also, the licensing issue will bite us (Debian) quite soon anyway.
Currently, we ship Ruby linked to libreadline5 (which is GPLv2). It is
likely that there will be a push to switch to libreadline6 (GPLv3), and
that will put us in an interesting situation when Ruby will be the only
application not having been switched to libreadline6.

29

On Mar 18, 2010, at 10:53 AM, Lucas N. wrote:

Of course, if you want to install many different Ruby and gems versions,
and then try to keep them in a sensible state wrt security issues (which
are not that uncommon in the ruby world), that’s your choice.

You have lost the high ground in the civility argument.

Why? What do you disagree with?

I wasn’t agreeing or disagreeing with anything. I was pointing out that
you yourself have stopped being civil in the quoted comments above.

James Edward G. II

30

On 19/03/10 at 00:35 +0900, James Edward G. II wrote:

and then try to keep them in a sensible state wrt security issues (which
are not that uncommon in the ruby world), that’s your choice.

You have lost the high ground in the civility argument.

Why? What do you disagree with?

31

On 19/03/10 at 01:01 +0900, James Edward G. II wrote:

making sure that their important software supports the latest API.
I wasn’t agreeing or disagreeing with anything. I was pointing out
that you yourself have stopped being civil in the quoted comments
above.

I disagree. I think that the following are true:

  • changing APIs is not considered a big problem in the ruby community
  • there are several versions of the interpreter being all widely used
    (ruby 1.8.6, 1.8.7, and to a lesser degree unfortunately, 1.9.X)
  • other scripting languages don’t have as many API problems as ruby
    (look at perl or python – well, python has some for python 3.X)
  • ruby has had several security issues over the past year. Every complex
    and famous software package has some, that’s life. But managing
    security when you have several versions co-installed manually is
    harder than when you just have to ‘apt-get upgrade’.

Note that I’m a Ruby fan, and also a ruby library developer. I’m the
original author for XMPP4R, for example. What I wrote above are just
facts about Ruby, not insults.

32

On 19/03/10 at 01:17 +0900, Rick DeNatale wrote:

are actually leveraging Ruby in such a way as to have conflicting
requirements with those of the debian packagers.

That’s very true. Note that, on the Debian side, we totally acknowledge
that Rubygems fills a need for some people (Ruby developers who want the
cutting edge software). However, the vision (from a part of the ruby
community) where everybody using Debian/Ubuntu is using apt-get to
install their normal application, but rubygems to install their ruby
applications, is not a realistic one.

about security issues not being uncommon in the ruby world.

In fact, although there have been security patches to Ruby/Rails etc.
They haven’t been more frequent than most other OSS software as far as
I have experienced, and certainly less than software from a certain
company headquartered in the US Pacific Northwest. And such security
patches are generally released quickly.

In fact having the ability to apply such changes, without having to
wait for them to be packaged ‘downstream’ is another advantage to
allowing ‘instability.’

Heh, I never wrote that Ruby is a security nightmare :stuck_out_tongue: There are
security issues in Ruby too, so that’s something to take into account
when considering several versions of ruby concurrently and from source.
I agree that the Ruby security history is not particularly bad.

33

On Thu, Mar 18, 2010 at 11:53 AM, Lucas N.
[email protected] wrote:

On Mar 18, 2010, at 10:15 AM, Lucas N. wrote:

Note there are not many development communities that are proud of the
fact of having different, incompatible versions of the same software
being widely used at the same time.

Most other communities solve that by having more stable APIs and making
sure that their important software supports the latest API.

I find the massive and rapid open source contributions to the overall
Ruby ecosystem to be a big source of pride in the Ruby community.

The fact that not everything needs to be on the same version of
everything is what allows fast movement.

Now I realize that there’s a different mindset between cutting-edge
development to deployment to system administration. Clearly having
less stability in the various pieces that make up various applications
raises some issues, and we, the Ruby community have been dealing with
those issues and getting better at it as time goes on.

Allowing that ‘instability’ is important to a lot of us, believe it or
not.

As I said before packaged Ruby solutions and re-packaged gems have
their place, they work for some users, but not for all.

In another reply to this thread you said:

Such a minor issue" was the split of many software packages into
seperate Debian packages, not the split of Ruby. …

Interestingly, we don’t get many complaints on the Debian side about
that. The only place where I hear about it is on this list.

I’m not sure what the antecedent of ‘that’ in the first sentence in
the second paragraph is. But I guess it doesn’t matter. Perhaps the
reason you only hear complaints about the debian packaging of Ruby and
gems here is that there’s a much higher proportion of users here who
are actually leveraging Ruby in such a way as to have conflicting
requirements with those of the debian packagers.

And as I said before, it’s not really an either or. You can run both
packaged ruby/gems if you need to in order to run other packages which
require them, along with multiple other installations outside of the
file system space clamed by debian policy within the FHS.

This whole discussion reminds me of the endless static vs. dynamic
typing debate. Some feel strongly that one should live within a
highly constrained infrastructure, others see benefits in having more
freedom of action, and are willing to deal with the consequences and
use tools and techniques which do that.

Of course, if you want to install many different Ruby and gems versions,
and then try to keep them in a sensible state wrt security issues (which
are not that uncommon in the ruby world), that’s your choice.

On 19/03/10 at 00:35 +0900, James Edward G. II wrote:

You have lost the high ground in the civility argument.

Why? What do you disagree with?

I can’t speak for James but perhaps he was reacting to the remark
about security issues not being uncommon in the ruby world.

In fact, although there have been security patches to Ruby/Rails etc.
They haven’t been more frequent than most other OSS software as far as
I have experienced, and certainly less than software from a certain
company headquartered in the US Pacific Northwest. And such security
patches are generally released quickly.

In fact having the ability to apply such changes, without having to
wait for them to be packaged ‘downstream’ is another advantage to
allowing ‘instability.’

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

34

Lucas N. wrote:

I really think that this problem is a minor one, and not worth all the
noise around it.

It may be a minor problem on the individual level, but a minor problem
which is very wide-spread becomes a much larger problem cumulatively.
Just changing the way the packages are named would probably solve this
minor-yet-common usability issue.

I’ll see with the other maintainers if there’s a way we
can improve the situation slightly. But the licensing issues involved
make me fear that it is unlikely.

Awesome, thanks for checking! Maybe making the “ruby” package part of
the repository that isn’t picky about licenses, and putting the
“ruby-minimal” package in the standard repository would help…

That’s not a reason to consider [a rude tone] acceptable.

Agreed! But since the problem will never be solved, we might as well
just accept that Internet anonymity causes temporary brain damage in
some people, and we should pity those so afflicted rather than let them
upset us :wink:

35

On Mar 18, 2010, at 11:16 AM, Lucas N. wrote:

I think that the following are true:

  • there are several versions of the interpreter being all widely used
    (ruby 1.8.6, 1.8.7, and to a lesser degree unfortunately, 1.9.X)

We don’t do this because we prefer it that way. Our language is in
transition.

  • other scripting languages don’t have as many API problems as ruby
    (look at perl or python – well, python has some for python 3.X)
  • ruby has had several security issues over the past year. Every complex
    and famous software package has some, that’s life. But managing
    security when you have several versions co-installed manually is
    harder than when you just have to ‘apt-get upgrade’.

These strike me as gross over generalizations.

James Edward G. II

36

Lucas N. wrote:

Note there are not many development communities that are proud of the
fact of having different, incompatible versions of the same software
being widely used at the same time.
Because Ruby is growing and moving quite fast at the moment. When it
slows down, there will be a major change in the general attitude of the
community regarding breaking code. Still, a young API can and most
likely should change. We all respect that - but now that’s beside the
point.

Most other communities solve that by having more stable APIs and making
sure that their important software supports the latest API.
Again… Growing community :wink:

In Debian Squeeze (next Debian release), we ship (and support for
several years) ruby 1.8 (likely 1.8.249+some backports) and ruby 1.9.1
(maybe a prerelease of 1.9.2, but unlikely). It would be totally insane,
to, additionally, try to support several versions of the same libraries.
Of course, if you want to install many different Ruby and gems versions,
and then try to keep them in a sensible state wrt security issues (which
are not that uncommon in the ruby world), that’s your choice.

Sorry to be a pain for you maintainers. Switch to Gentoo :wink: It handles
all that very well, and has done a fantastic job of handling an overlay
tree for gems - you can essentially get the gems installed and supported
by your distribution. It is of course far from perfect, but they’re
doing a fine job of it.
Then again, they have just recently started handling license acceptance
for things like Java, VMWare and such, so Debian is eons ahead of them
in that regard – which is in fact at the core of our current debate.

Also: don’t let the unfriendly tone one often encounters on the internet
get ya down. The medium itself seems to encourage that sort of thing…

That’s not a reason to consider it acceptable.

True enough, OTOH, I’ve found it a lot easier to live on the
inter-tubes if I develop a thick skin, and give everyone the benefit
of the doubt that they are not actively trying to be uncivil, even if
they express themselves in what I might perceive to be an uncivil
fashion.

It’s really to give the benefit of the doubt about civility to several
people on this list.

Normal person + Anonymity + Audience = Total fscktard. It’s a
penny-arcade rule, and it’s true. May as well be called “The Law of Gabe
& Tyco”, or whatever their names are.
For whatever it’s worth, Lucas, I have tremendous respect for the work
you do as a package maintainer. It’s hard, time-consuming, sometimes
tedious, and sadly most of the time very thankless, as it is completely
behind the scenes.

Besides the issue of licensing mentioned above, the only other real
issue mentioned in this thread is “What will the users think?” or WWUT,
which can clearly be brought back to WWJDIHHAC (What would Jesus do if
he had a computer). JEG II made a change on Ruby’s website to help
educating the users. Is it possible to add a message of some sort to the
pre-install apt-get warning when installing Ruby, to explain the
different Ruby packages?
I know it’s not exactly Standard Operating Procedure for Debian, but
again, Ruby moves very fast, much faster than Debian does - which is not
a qualification, just a comparison.

37

On Thu, Mar 18, 2010 at 11:01 AM, Lucas N.
[email protected] wrote:

Your first sentence is incorrect; OpenSSL is both better known and
could reasonably replace the OpenSSL namespace and that both “require
‘openssl’” and “require ‘gnutls’” would satisfy, then I think we’d see
traction. Since this is apparently a problem for people who prefer GNU
TLS, I suggest that it is in their interest to do so.

Note that your lawyer might disagree with you, whether he is a GNU
fanboy or not, because it is widely agreed that the OpenSSL license is
incompatible with the GPL.

I agree that this sucks, but hey, that’s life.

I see it the other way around; because the GNU GPL does not permit
attribution requirements, it is the GNU GPL which is incompatible with
the (older) BSD-style license. I agree that it’d be nicer if OpenSSL
and SSLeay were under the 3-clause BSD, but I understand exactly why
they do it.

To me, the 4±clause BSD is far more acceptable than any GNU GPL
license, even the GNU LGPL, even v2 (which I think is an infinitely
superior license to v3, but that’s just my opinion).

Lawyers will agree that there’s a distribution incompatibility since
the GNU GPL doesn’t permit attribution requirements and OpenSSL
requires it under two different licences. That is the key point, but
the FSF has already pointed a way out of this: write to a common API
that can be used transparently and allow end users (who are not
subject to redistribution requirements in any case) to swap out their
preferred implementation.

This is exactly what the FSF says should be done to deal with their
(likely incorrect) understanding of shared object linking especially
with respect to libreadline.

Since Ruby programmers and the Ruby language have no problem as such
with OpenSSL, I would suggest that it is up to GNU TLS supporters to
write that transparent layer and convince Rubyists to use it. GNU TLS
has a fraction of the users over OpenSSL.

-austin

38

On Thu, Mar 18, 2010 at 11:02 AM, Lucas N.
[email protected] wrote:

maintenance.)
Yes, it is. Let me be very clear in saying that the situation in the
last two years is, while far from ideal, significantly better than it
used to be. For that, let me say thank you. I disagree with you on a
number of things (including the fact that I think that Debian still
has a long way to go toward getting it right), but your maintenance is
appreciated and things are better than they used to be.

All of the standard libraries are meant to be
installed so you can count on having them. By changing that decision,
Debian has made it so you can’t count on having them and that changes
the rules of what you can do with Ruby.
If, maybe, the Ruby community fixed the fact that it’s illegal to load
all of stdlib in the same process (because of OpenSSL vs GPL), we could
consider including ssl and readline in the default lib pkg. However, I don’t
see how we will make Ruby depend on installing Tcl/Tk (because of the TK
bindings), or Emacs (because of the ruby mode for emacs). Note that even
ruby-full doesn’t install the TK and elisp stuff.

Please don’t repeat this, because as I pointed out on ruby-core, it’s
not true. it’s not illegal to load libreadline and openssl in the same
process; it’s illegal to ship software that contains both. Neither the
OpenSSL license nor the GNU GPL address use or incidental in-memory
copies, only distribution.

-austin

39

On 19/03/10 at 02:49 +0900, Aldric G. wrote:

tree for gems - you can essentially get the gems installed and supported
by your distribution. It is of course far from perfect, but they’re
doing a fine job of it.
Then again, they have just recently started handling license acceptance
for things like Java, VMWare and such, so Debian is eons ahead of them
in that regard – which is in fact at the core of our current debate.

I think that rubygems and emerge and actually quite similar, which
probably explains why they work together well. Rubygems is a great tool
for developers who want to get the latest cutting edge software.
However, at some point, applications are transferred from developers to
sysadmins, and “cutting edge” isn’t really a good selling point.
Internally (in an organization) it’s fine, because you can just
vendorize all the gems you use. But if you want to distribute your
application to the outside world, it’s difficult to explain that the
user needs to use rubygems to install that application because it’s
written in ruby, while the ruby is just interested in the functionality
provided by the application, and doesn’t care whether it’s perl or ruby.

I think that approaches that aim at getting rubygems and apt-get to
cooperate are just wrong. Both rubygems and apt-get have good reasons to
exist, but they don’t solve the same problem. Instead, we should try to
develop a set of good practices that make it easier to convert a ruby
library into a “normal” Deb or RPM package. Much progress has already
been done lately, and the last libraries I’ve packaged didn’t use
“require ‘rubygems’” except in the test suite, so they did not require
any patching.

We are currently trying to finish the releases for Ubuntu Lucid and
Debian Squeeze (in order of appearance ;). After that, it is likely that
the way we package ruby libraries in Debian will be discussed with the
goal to make it easier to support both ruby 1.8 and 1.9.X (I don’t see
Ruby 1.8 disappearing during the next 2.5 years). This discussion will
also be a good opportunity to discuss other aspects of Ruby packaging.

Besides the issue of licensing mentioned above, the only other real
issue mentioned in this thread is “What will the users think?” or WWUT,
which can clearly be brought back to WWJDIHHAC (What would Jesus do if
he had a computer). JEG II made a change on Ruby’s website to help
educating the users. Is it possible to add a message of some sort to the
pre-install apt-get warning when installing Ruby, to explain the
different Ruby packages?

I have kind-of done that a few hours ago.

Before:

apt-get install ruby

Reading package lists… Done
Building dependency tree
Reading state information… Done
The following extra packages will be installed:
libruby1.8 ruby1.8
Suggested packages:
ruby1.8-examples rdoc1.8 ri1.8
The following NEW packages will be installed:
libruby1.8 ruby ruby1.8
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 2041kB of archives.
After this operation, 6644kB of additional disk space will be used.

Now:

apt-get install ruby

Reading package lists… Done
Building dependency tree
Reading state information… Done
The following extra packages will be installed:
libruby1.8 ruby1.8
Suggested packages:
irb rdoc ri libopenssl-ruby ruby-dev ruby1.8-examples rdoc1.8 ri1.8
The following NEW packages will be installed:
libruby1.8 ruby ruby1.8
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 2060kB/2082kB of archives.
After this operation, 6980kB of additional disk space will be used.

(See the list of Suggested packages)

It’s not much, but still a slight improvement, which should probably
have been done before.

40

Lucas N. wrote:

On 19/03/10 at 02:49 +0900, Aldric G. wrote:

tree for gems - you can essentially get the gems installed and supported
by your distribution. It is of course far from perfect, but they’re
doing a fine job of it.
Then again, they have just recently started handling license acceptance
for things like Java, VMWare and such, so Debian is eons ahead of them
in that regard – which is in fact at the core of our current debate.

I think that rubygems and emerge and actually quite similar, which
probably explains why they work together well. Rubygems is a great tool
for developers who want to get the latest cutting edge software.
However, at some point, applications are transferred from developers to
sysadmins, and “cutting edge” isn’t really a good selling point.

I think that approaches that aim at getting rubygems and apt-get to
cooperate are just wrong. Both rubygems and apt-get have good reasons to
exist, but they don’t solve the same problem. Instead, we should try to
develop a set of good practices that make it easier to convert a ruby
library into a “normal” Deb or RPM package. Much progress has already
been done lately, and the last libraries I’ve packaged didn’t use
“require ‘rubygems’” except in the test suite, so they did not require
any patching.

Apt-get does not really handle slotting in the way portage does, and I
think that’s what you are thinking about when you say that rubygems and
portage work the same way.
Rubygems isn’t meant for what you describe, but I agree that it helps
that behavior. Its purpose is to manage different versions of gems
because it understands that purposes and APIs can change.
Did we mention that gems can be released under whatever license the
owner wants? What a nightmare for Debian’s apt-get system…
I’m glad to hear that it’s becoming easier to integrate libs into
apt-get.

Someone suggested, earlier, that we add ruby to a different branch of
the debian sources. How about creating a separate tree for the gems,
where the updating can be done more quickly than on the regular tree? Is
that idea a no-go because of Debian policies (of which I am blissfully
ignorance) ?

Is it possible to add a message of some sort to the
pre-install apt-get warning when installing Ruby, to explain the
different Ruby packages?

I have kind-of done that a few hours ago.

Now:

apt-get install ruby

Reading package lists… Done
Building dependency tree
Reading state information… Done
The following extra packages will be installed:
libruby1.8 ruby1.8
Suggested packages:
irb rdoc ri libopenssl-ruby ruby-dev ruby1.8-examples rdoc1.8 ri1.8
The following NEW packages will be installed:
libruby1.8 ruby ruby1.8
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 2060kB/2082kB of archives.
After this operation, 6980kB of additional disk space will be used.

(See the list of Suggested packages)

It’s not much, but still a slight improvement, which should probably
have been done before.

That’s great - I think it’s probably the best way to start. The rest
will come down to meetings and long discussions about policies… :slight_smile:
Now if only users would read ! :stuck_out_tongue:

– Aldric G.
What is the source of conflict?