Recommended way to install Rubygems
Leslie Viljoen
Hi!
I am trying to install Ruby1.9.1 under Ubuntu 9.10 - with gems. I can
"apt-get install ruby1.9.1", but I have often had trouble
mixing package managers and installing rubygems using apt-get so I usually
download it. I also see warnings on the 'net
that installing rubygems using apt-get is not recommended.
Contrary to http://ryanbigg.com/2009/01/ruby-191-rubygems-rails/, rubygems
does not come included with ruby1.9.1 on Ubuntu,
I suppose because it is packaged separately (perhaps wrongly?)
So what I have tried to do is install gems by running the setup.rb program
using ruby1.9.1. This seems to work, and I then
get a gem1.9.1 which I can use to install gems. But when I try to require
those gems, they seem to be missing:
$ gem1.9.1 list
*** LOCAL GEMS ***
file-find (0.3.4)
sys-admin (1.5.2)
$ irb1.9.1
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'file/find'
LoadError: no such file to load -- file/find
so... should I be using apt-get?
--
Windows is a fitting punishment for those who choose it - I just wish I
didn't have to be punished along with them.
robb
If you do choose to install via apt, here's the Ubuntu documentation on
RubyGems from the Rails page:
https://help.ubuntu.com/community/RubyOnRails#Installing RubyGems
Eric Hodel
> I am trying to install Ruby1.9.1 under Ubuntu 9.10 - with gems. I can
> "apt-get install ruby1.9.1", but I have often had trouble
> mixing package managers and installing rubygems using apt-get so I usually
> download it. I also see warnings on the 'net
> that installing rubygems using apt-get is not recommended.
>
> Contrary to http://ryanbigg.com/2009/01/ruby-191-rubygems-rails/, rubygems
> does not come included with ruby1.9.1 on Ubuntu,
> I suppose because it is packaged separately (perhaps wrongly?)
>
> So what I have tried to do is install gems by running the setup.rb program
> using ruby1.9.1. This seems to work, and I then
> get a gem1.9.1 which I can use to install gems. But when I try to require
> those gems, they seem to be missing:
>
>
> $ gem1.9.1 list
>
> *** LOCAL GEMS ***
>
> file-find (0.3.4)
> sys-admin (1.5.2)
> $ irb1.9.1
> irb(main):001:0> require 'rubygems'
> => true
> irb(main):002:0> require 'file/find'
> LoadError: no such file to load -- file/find
>
>
> so... should I be using apt-get?
Maybe there's a package with all of ruby instead of just the pieces that ubuntu thinks constitutes ruby.
My recommendation is to install all of ruby by hand instead of using apt-get.
Lucas Nussbaum
notice replies)
In the past, we (Debian Ruby maintainers, so de-facto Ubuntu Ruby
maintainers since Ubuntu just imports the Ruby packages from Debian) had
problems with the fact that rubygems was shipped with the Ruby
interpreter itself: some gems required a version of rubygems that was
more recent than the one provided by the interpreter.
So the decision was taken to get rubygems directly from upstream,
independantly of the version shipped in ruby 1.8.X or ruby 1.9.1.Y.
Now, on the fact that ruby is split out into several packages, it is
justified by the fact that some ruby apps don't require all the native
libraries normally built with the interpreter (readline, openssl, etc).
To cut off the number of other packages needed on a minimal system that
would just need a ruby interpreter without, say, readline, some of the
native libraries are packaged separately, in the following packages:
libdbm-ruby1.9.1, libgdbm-ruby1.9.1, libreadline-ruby1.9.1,
libtcltk-ruby1.9.1, libopenssl-ruby1.9.1.
For users who want to install "all of ruby", we also provide two
packages that only depend on all the other packages: ruby-full (for 1.8)
and ruby1.9.1-full (for 1.9.1, obviously).
I hope this clarifies the status of Ruby in Debian and Ubuntu a bit.
Also, it would be great if all the sarcasm and nasty comments on this
list each time someone brings up Ruby and Debian or Ubuntu could be
reduced a bit. I am working on providing Ruby packages in Debian and
Ubuntu as a volunteer, and don't really enjoy all the flames I get on
this list. Constructive criticism is welcomed (preferably as bug
reports), but is very rare here, unfortunately.
--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
Eric Hodel
> I hope this clarifies the status of Ruby in Debian and Ubuntu a bit.
> Also, it would be great if all the sarcasm and nasty comments on this
> list each time someone brings up Ruby and Debian or Ubuntu could be
> reduced a bit. I am working on providing Ruby packages in Debian and
> Ubuntu as a volunteer, and don't really enjoy all the flames I get on
> this list. Constructive criticism is welcomed (preferably as bug
> reports), but is very rare here, unfortunately.
Unfortunately I end up having to handle most of the issues that Debian creates due to their splitting up Ruby into multiple packages because of the way it affects Ruby and RubyGems. I can reduce my support load and increase my free time by saying "install all of Ruby and RubyGems by hand on Debian and Ubuntu". Once RubyGems is installed it's fairly smooth sailing on Debian unless you install a gem that needs to compile against missing headers.
It's especially frustrating when features are added to RubyGems that have the express goal of helping Debian and Ubuntu are either ignored (rubygems/defaults/operating_system, added in 1.2.0) or are rejected for what seems to boil down to policy reasons (Neil Wilson's work in http://bugs.debian.org/403407).
When you say things like:
> The problem is that the upstream rubygems developers don't care, and that it's impossible to change that without their cooperation.
I don't see how we (that work on RubyGems) could possibly have ever cared if you're not subscribed to the mailing list where you would raise those concerns nor have you filed any bugs with any of these concerns.
We certainly can't cooperate when you don't bother to raise any issues in the places we're looking for them.
PS:
Not taking advantage of rubygems/defaults/operating_system is especially odd to me as it would allow upgrades of RubyGems to continue to work while maintaining Debian's customizations. Last I checked the only changes made to RubyGems by Debian could be encapsulated in this one file.
PPS:
Maybe you get so much sarcasm and nasty comments because people are genuinely frustrated with what Debian provides by default. Maybe installing ruby-full by default instead of the minimal ruby will reduce your frustrations.
Oftentimes people are following instructions they found on the web that were written for non-Debian/Ubuntu. On OS X, BSD, and most other Linux versions those instructions will work without modification, but since Debian is subtly different they end up coming here and we end up answering the same questions over and over, which will inevitably lead to us making sarcastic, nasty comments.
From maintaining RubyGems I've learned that maintaining a large, popular open-source library requires a thick skin and the ability to say "yeah, what I'm doing is not what people want" sometimes.
Nick Brown
Might I suggest that the package called "ruby" install the standard
ruby, with everything? This would reduce confusion (and disapproving
comments) very much.
If you really think there is big demand for minimal ruby installs, go
ahead and have a ruby-minimal package, too. But you should know that
many people, especially newbies, are mislead by calling something "ruby"
which is actually "partial-ruby".
--
Posted via http://www.ruby-forum.com/.
gf
trying to hit a very elusive target, and often probably working from a
poor set of requirements as far as what we, the users, want.
I always wanted a current package of Ruby with rubygems installed, the
drivers for Postgres and MySQL, SSL support, and libxml2 and Nokogiri.
That would give me the ability to process XML and HTML, talk to the
two primary DBs I've used over the last five years, talk to secured
services on the internet, etc., as soon as the install finished. As
is, I've always had to do those things before I could start to use
Ruby on a box in our enterprise.
That's just my $0.02 wishlist.
gf
I had. It was easier to install from source so I had current revisions
of Ruby, and to manage all my gems by hand.
When rvm came out I switched to it and now it's my favorite way to go
on Mac OS and Ubuntu because it handles the grunt work of maintaining
multiple versions of Ruby, allows gem bundles, and makes it trivial to
switch from one version of Ruby to another when testing.
Lucas Nussbaum
> On Mar 17, 2010, at 14:32, Lucas Nussbaum wrote:
>
> > I hope this clarifies the status of Ruby in Debian and Ubuntu a bit.
> > Also, it would be great if all the sarcasm and nasty comments on
> > this list each time someone brings up Ruby and Debian or Ubuntu
> > could be reduced a bit. I am working on providing Ruby packages in
> > Debian and Ubuntu as a volunteer, and don't really enjoy all the
> > flames I get on this list. Constructive criticism is welcomed
> > (preferably as bug reports), but is very rare here, unfortunately.
>
> Unfortunately I end up having to handle most of the issues that Debian
> creates due to their splitting up Ruby into multiple packages because
> of the way it affects Ruby and RubyGems. I can reduce my support load
> and increase my free time by saying "install all of Ruby and RubyGems
> by hand on Debian and Ubuntu". Once RubyGems is installed it's fairly
> smooth sailing on Debian unless you install a gem that needs to
> compile against missing headers.
>
> It's especially frustrating when features are added to RubyGems that
> have the express goal of helping Debian and Ubuntu are either ignored
> (rubygems/defaults/operating_system, added in 1.2.0) or are rejected
> for what seems to boil down to policy reasons (Neil Wilson's work in
> http://bugs.debian.org/403407).
Are you aware of the tone you use in this discussion? "issues that
Debian creates" kind-of implies that we create issues on purpose.
"reject for what seems to boil down to policy reasons" implies that you
consider that what our policy might be should probably be ignored if it
fixed your problem.
> When you say things like:
>
> > The problem is that the upstream rubygems developers don't care, and
> > that it's impossible to change that without their cooperation.
>
> I don't see how we (that work on RubyGems) could possibly have ever
> cared if you're not subscribed to the mailing list where you would
> raise those concerns nor have you filed any bugs with any of these
> concerns.
>
> We certainly can't cooperate when you don't bother to raise any issues
> in the places we're looking for them.
There was attempts (by me and others) to try to improve the situation.
Given how the rubygems tend to see the problem, I've given up, because
it's better for my mental health not to engage into discussions with
poisonous people that kill all the fun.
> Not taking advantage of rubygems/defaults/operating_system is
> especially odd to me as it would allow upgrades of RubyGems to
> continue to work while maintaining Debian's customizations. Last I
> checked the only changes made to RubyGems by Debian could be
> encapsulated in this one file.
When did you last check? You didn't know about ruby-full/ruby1.9.1-full,
so I assume that must have been a long time ago.
> Maybe you get so much sarcasm and nasty comments because people are
> genuinely frustrated with what Debian provides by default. Maybe
> installing ruby-full by default instead of the minimal ruby will
> reduce your frustrations.
Well, people are also frustrated the other way around, because they are
required by some ruby developers to use rubygems instead of apt-get,
which they can use for all other scripting languages out there.
> Oftentimes people are following instructions they found on the web
> that were written for non-Debian/Ubuntu. On OS X, BSD, and most other
> Linux versions those instructions will work without modification, but
> since Debian is subtly different they end up coming here and we end up
> answering the same questions over and over, which will inevitably lead
> to us making sarcastic, nasty comments.
>
> From maintaining RubyGems I've learned that maintaining a large,
> popular open-source library requires a thick skin and the ability to
> say "yeah, what I'm doing is not what people want" sometimes.
I actually think that the Rubygems situation in Debian is "OK". I don't
see how changing the way the packages are split would improve the
situation. Could you point to specific problems that people have? I'm
aware of two problems:
- the location of installed gems in Debian (in /var instead of /usr),
but that is dictated by policy. I *personally* would have preferred to
follow what rubygems does, but I was not directly in charge of that
decision.
- the fact that, when you try to install a gem, you might need to
install some other packages that are required to build that specific
gem (packages containing header files, compiler, etc). What is
currently done is that installing rubygems suggests (in the package
manager sense) to install the ruby header files, and a
"build-essential" package that depends on gcc, g++, etc. I can't see
what else we could do, given that:
+ some people might want to install only pure-ruby gems, so requiring
them to install a compiler and header files when installing rubygems
would be annoying.
+ we can't guess in advance which other header files will be needed by
the user (= the user installs rubygems just to install the
"ruby-foo" gem, that requires the headers for "libfoo" to be installed).
We provide tools in Debian that allow the user to know
which package contains a specific file. Of course we can't just
require the installation of all the packages containing header
files in Debian.
Are you aware of other issues?
Note that our position is rather accurately described in
http://pkg-ruby-extras.alioth.debian.org/rubygems.html
We currently don't have any real problem with rubygems itself. Most of
our problems are caused by gem developers (those developing libraries,
not those developing rubygems itself) that ship libraries as .gem only
(so we need to repackage the source as a .tgz), or that ship code that
uses "require 'rubygems'", that we have to patch out before installing
with setup.rb. However, that recommended practice is changing slowing in
the good direction, which is great.
Lucas Nussbaum
Which parts of ruby which are currently split out would you like to see
installed when the user installs ruby? For example, ruby ships a ruby
emacs mode. Installing that would require adding a dependency on emacs,
which doesn't sound reasonable.
Anyway, I've just added the following packages to the list of packages
that are "suggested" when someone installs ruby: irb, rdoc, ri,
libopenssl-ruby, ruby-dev.
That doesn't mean that they are installed automatically when the user
installs "ruby", but the package manager will suggest to install those
packages too.
Lucas Nussbaum
Isn't that available if you apt-get install ruby rubygems libpgsql-ruby
libmysql-ruby libopenssl-ruby libxml-ruby libnokogiri-ruby?
I hope you understand that it is not reasonable to expect this to be
part of the default Debian install, or even to expect that installing
"ruby" would install "libpgsql-ruby libmysql-ruby libopenssl-ruby
libxml-ruby libnokogiri-ruby" too.
Ryan Davis
On Mar 18, 2010, at 00:47 , Lucas Nussbaum wrote:
> Which parts of ruby which are currently split out would you like to see
> installed when the user installs ruby? For example, ruby ships a ruby
> emacs mode. Installing that would require adding a dependency on emacs,
> which doesn't sound reasonable.
That's a bullshit rationalization. All the other platforms install that file just fine. None of the installs fail if emacs isn't available.
Install everything. Make `ruby` work exactly as it works everywhere else. Anything less is a disservice to your own users.
Lucas Nussbaum
>
> On Mar 18, 2010, at 00:47 , Lucas Nussbaum wrote:
>
> > Which parts of ruby which are currently split out would you like to see
> > installed when the user installs ruby? For example, ruby ships a ruby
> > emacs mode. Installing that would require adding a dependency on emacs,
> > which doesn't sound reasonable.
>
> That's a bullshit rationalization.
See why I don't want to discuss this? ;-)
botp
<lu...@lucas-nussbaum.net> wrote:
> On 18/03/10 at 17:10 +0900, Ryan Davis wrote:
>>
>> On Mar 18, 2010, at 00:47 , Lucas Nussbaum wrote:
>>
>> > Which parts of ruby which are currently split out would you like to see
>> > installed when the user installs ruby? For example, ruby ships a ruby
>> > emacs mode. Installing that would require adding a dependency on emacs,
>> > which doesn't sound reasonable.
>>
>> That's a bullshit rationalization.
>
> See why I don't want to discuss this? ;-)
i am w Lucas here.
As to distros, i prefer debian/ubuntu when it comes to ruby. At least
they (deb) are least crappy when it comes to breakage.
Of course, if you want to have full control (specially in prodxn), i
install by source, and only what i need (not all).
Those who want all, there's a one-click i think, or anybody can just
script all those....
just my 2cents
kind regards -botp
ps: as for nubiness, .. who says developing is easy, yes ruby is, but... ;-)
Nick Brown
> Which parts of ruby which are currently split out would you like to see
> installed when the user installs ruby? For example, ruby ships a ruby
> emacs mode. Installing that would require adding a dependency on emacs,
> which doesn't sound reasonable.
>
> Anyway, I've just added the following packages to the list of packages
> that are "suggested" when someone installs ruby: irb, rdoc, ri,
> libopenssl-ruby, ruby-dev.
> That doesn't mean that they are installed automatically when the user
> installs "ruby", but the package manager will suggest to install those
> packages too.
Well, I don't know about emacs... I don't recall ever needing to install
emacs before installing ruby even from source, but on the other hand,
disk space and bandwidth are so cheap these days I wouldn't care one way
or the other.
But just yesterday I was trying to install mechanize (via rubygems) on
my 9.10 system, and it kept failing because 'net/https' was missing. And
I was scratching my head wonder why the heck a core piece of ruby like
that wouldn't be there... I thought perhaps my disk was going dead on
me... I eventually figured out what was up after some searching of the
net, but I think this illustrates the sort of confusion that can arise.
The easiest way to solve this problem would be to rename "ruby" to
"ruby-core" or something, then rename "ruby-full" to "ruby". This would
allow the few who want partial ruby installs to still do so, but the
great masses of users (and hosting providers!) who expect the package
called "ruby" to be all of ruby will be spared confusion and
frustration.
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...
Your work IS appreciated! Keep in mind that it is Debian policy, not you
personally, that seems to be the true target of the frustrations.
Brian Candler
> installed when the user installs ruby?
For me, the biggest surprise was discovering net/https.rb was missing
entirely, and wondering why on earth part of the ruby 'standard library'
had vanished. Eventually I found it had been separated out into
libopenssl-ruby.
It's also confusing that irb, ri, rdoc are missing by default.
I understand the logic, kind of. Maybe someone wants to build a tiny
system with ruby but without openssl (*).
Obviously it's not easy to know where to draw the line (should
installing ruby force installation of tcl/tk?), but I think the majority
of users are going to want net/https, readline and irb, and be surprised
if they are missing. There are few systems which won't have the openssl
and readline dependencies already present.
So I would also vote that 'ruby' be a meta-package to pull in the
complete set.
Regards,
Brian.
(*) A similar split exists in openwrt, which is explicitly targeted at
tiny systems. Indeed, they fragment it more so that you don't have to
install yaml or rexml if you don't want them.
Lucas Nussbaum
> Lucas Nussbaum wrote:
> > Which parts of ruby which are currently split out would you like to see
> > installed when the user installs ruby? For example, ruby ships a ruby
> > emacs mode. Installing that would require adding a dependency on emacs,
> > which doesn't sound reasonable.
> >
> > Anyway, I've just added the following packages to the list of packages
> > that are "suggested" when someone installs ruby: irb, rdoc, ri,
> > libopenssl-ruby, ruby-dev.
> > That doesn't mean that they are installed automatically when the user
> > installs "ruby", but the package manager will suggest to install those
> > packages too.
>
> Well, I don't know about emacs... I don't recall ever needing to install
> emacs before installing ruby even from source, but on the other hand,
> disk space and bandwidth are so cheap these days I wouldn't care one way
> or the other.
In Debian, we do not ship software without appropriately describing what
other packages are required (as dependencies) to use it. ruby1.8-elisp
is a separate package that depends on emacs, so that is fine. But if we
wanted to ship the content of ruby1.8-elisp inside an hypothetical
full-featured ruby package, the right thing to do would be to depend on
emacs. This could become an interesting issue on some of the
architecture debian supports.
> But just yesterday I was trying to install mechanize (via rubygems) on
> my 9.10 system, and it kept failing because 'net/https' was missing. And
> I was scratching my head wonder why the heck a core piece of ruby like
> that wouldn't be there... I thought perhaps my disk was going dead on
> me... I eventually figured out what was up after some searching of the
> net, but I think this illustrates the sort of confusion that can arise.
OpenSSL doesn't have a lot of fans, because of its licence that prevents
it from being linked to GPL software. Yes, it could be possible to ship
openssl.so and readline.so in the same package, but then it would be
harder to argue that Debian does enough to protect the linking of
readline (GPLv2) with openssl. The situation would be much simpler if
Ruby switched to GNU TLS, for example.
> The easiest way to solve this problem would be to rename "ruby" to
> "ruby-core" or something, then rename "ruby-full" to "ruby". This would
> allow the few who want partial ruby installs to still do so, but the
> great masses of users (and hosting providers!) who expect the package
> called "ruby" to be all of ruby will be spared confusion and
> frustration.
I really think that this problem is a minor one, and not worth all the
noise around it. 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.
> 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.
Austin Ziegler
<lu...@lucas-nussbaum.net> wrote:
> OpenSSL doesn't have a lot of fans, because of its licence that prevents
> it from being linked to GPL software. Yes, it could be possible to ship
> openssl.so and readline.so in the same package, but then it would be
> harder to argue that Debian does enough to protect the linking of
> readline (GPLv2) with openssl. The situation would be much simpler if
> Ruby switched to GNU TLS, for example.
Your first sentence is incorrect; OpenSSL is both better known and
more widely used in the real world than GNU TLS is likely to ever be.
GNU TLS is preferred by people who have subscribed to the GNU
philosophy, which doesn't include everyone in the Ruby world, and
those of us who prefer OpenSSL see GNU TLS as a zany outlier created
by people who have nothing better to do with their time than to worry
about the attribution clause (I believe that's the part that makes GNU
software incompatible with OpenSSL licensing, since GNU believes that
attribution isn't necessary).
That said, if someone were to make an SSL/TLS layer for Ruby that
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.
-austin
--
Austin Ziegler • halos...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue
James Edward Gray II
> But just yesterday I was trying to install mechanize (via rubygems) on
> my 9.10 system, and it kept failing because 'net/https' was missing. And
> I was scratching my head wonder why the heck a core piece of ruby like
> that wouldn't be there...
I completely agree that the split sucks. We run a Ruby service that requires our users to install a simple script on their servers. It does use net/https to communicate, so about 80% of our support issues 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. 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.
> The easiest way to solve this problem would be to rename "ruby" to
> "ruby-core" or something, then rename "ruby-full" to "ruby". This would
> allow the few who want partial ruby installs to still do so, but the
> great masses of users (and hosting providers!) who expect the package
> called "ruby" to be all of ruby will be spared confusion and
> frustration.
I completely agree. It's fine for Debian to offer lighter installs, but installing Ruby should mean I get Ruby as it was meant to be. That has to be the default to be correct, in my opinion.
James Edward Gray II
Brian Candler
> OpenSSL doesn't have a lot of fans
<wikipedia>Citation Needed</wikipedia>
(give me BSD-licensed code any day)
Rick DeNatale
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
Lucas Nussbaum
> Lucas Nussbaum wrote:
> > OpenSSL doesn't have a lot of fans
>
> <wikipedia>Citation Needed</wikipedia>
>
> (give me BSD-licensed code any day)
http://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_.28original_.22BSD_License.22.29
(which is the version of the BSD license that OpenSSL uses. If it was
the 3-clauses BSD license, there would be no problem.)
Lucas Nussbaum
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.
Lucas Nussbaum
> On Mar 18, 2010, at 9:05 AM, Nick Brown wrote:
>
> > But just yesterday I was trying to install mechanize (via rubygems)
> > on my 9.10 system, and it kept failing because 'net/https' was
> > missing. And I was scratching my head wonder why the heck a core
> > piece of ruby like that wouldn't be there...
>
> I completely agree that the split sucks. We run a Ruby service that
> requires our users to install a simple script on their servers. It
> does use net/https to communicate, so about 80% of our support issues
> 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
http://www.ruby-lang.org/en/downloads/. 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.
Lucas Nussbaum
> 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.
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.
James Edward Gray II
> On 18/03/10 at 23:31 +0900, James Edward Gray II wrote:
>> On Mar 18, 2010, at 9:05 AM, Nick Brown wrote:
>>
>>> But just yesterday I was trying to install mechanize (via rubygems)
>>> on my 9.10 system, and it kept failing because 'net/https' was
>>> missing. And I was scratching my head wonder why the heck a core
>>> piece of ruby like that wouldn't be there...
>>
>> I completely agree that the split sucks. We run a Ruby service that
>> requires our users to install a simple script on their servers. It
>> does use net/https to communicate, so about 80% of our support issues
>> 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
> http://www.ruby-lang.org/en/downloads/. You might want to educate your
> users to read the documentation.
I added that to the site recently to help with this issue. ;) (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 Gray II
James Edward Gray II
> 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 Gray II
Lucas Nussbaum
"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.
> >> 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.)
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.
Lucas Nussbaum
Why? What do you disagree with?
James Edward Gray II
> On 19/03/10 at 00:35 +0900, James Edward Gray II wrote:
>> On Mar 18, 2010, at 10:15 AM, Lucas Nussbaum 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.
>
> 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 Gray II
Lucas Nussbaum
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.
Rick DeNatale
<lu...@lucas-nussbaum.net> wrote:
>> On Mar 18, 2010, at 10:15 AM, Lucas Nussbaum 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 Gray 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.'
Lucas Nussbaum
> > 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.
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.
> >> > 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 Gray 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.'
Heh, I never wrote that Ruby is a security nightmare :P 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.
James Edward Gray II
> 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 Gray II
Nick Brown
> 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 ;-)
Austin Ziegler
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.
Aldric Giacomoni
>
> 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.
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.
>
> 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 ;-) 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.
Austin Ziegler
<lu...@lucas-nussbaum.net> wrote:
> Apparently, the ruby core team is OK with the current situation, since
> apt-get install ruby1.9.1-full/ruby-full is advertised on
> http://www.ruby-lang.org/en/downloads/. 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.)
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.
Seebs
> 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.
The issue is, historically, that the FSF has claimed that a program
written to use the libreadline API is thereby a "derivative work" of
libreadline. A while back, they were arguing that the only way this
would be untrue would be if someone were to create a call-compatible
"readline" implementation, so that code couldn't be shown to be
unable to work without libreadline.
Which is funny, because I know of at least one such implementation dating
back to 1992. Rich $alz posted it, with these terms:
X Permission is granted to anyone to use this software for any purpose on
X any computer system, and to alter it and redistribute it freely, subject
X to the following restrictions:
X 1. The authors are not responsible for the consequences of use of this
X software, no matter how awful, even if they arise from flaws in it.
X 2. The origin of this software must not be misrepresented, either by
X explicit claim or by omission. Since few users ever read sources,
X credits must appear in the documentation.
X 3. Altered versions must be plainly marked as such, and must not be
X misrepresented as being the original software. Since few users
X ever read sources, credits must appear in the documentation.
X 4. This notice may not be removed or altered.
(Yes, it was a shar script.)
Long story short: There hasn't been a problem with stuff merely designed
to work with readline or something compatible with it since 1992 or possibly
earlier.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Lucas Nussbaum
> > 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 ;-) 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.
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.
Leslie Viljoen
On Thu, Mar 18, 2010 at 8:47 PM, Lucas Nussbaum <lu...@lucas-nussbaum.net>wrote:
> On 19/03/10 at 02:49 +0900, Aldric Giacomoni wrote: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.
>
Can I ask: how do Perl and Python deal with this? CPAN is included in the
base Perl install - how does Perl deal
with the fact that CPAN then installs its own stuff?
Is it safe to install RubyGems via apt-get now? I have seen warnings but I
don't know the actual reason behind them.
Aldric Giacomoni
> On 19/03/10 at 02:49 +0900, Aldric Giacomoni 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.
>
>
> 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.
>
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.. :)
Now if only users would _read_ ! :p
-- Aldric Giacomoni
What is the source of conflict?
Lucas Nussbaum
> 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) ?
You could create an external repository with unofficial (as in: not in
Debian) packages that are built automatically from gems. I think that
this was actually already done (see http://www.debgem.com/), but I'm not
sure of the status of this project. There's nothing blocking anybody
from doing that.
However, those debs are likely not suitable to be directly integrated in
Debian. In Debian, we install Ruby libraries under /usr/lib/ruby/1.8
(with a migration to /usr/lib/ruby/vendor_ruby/1.8 planned, but not done
yet, to avoid mixing the stdlib with third-party libs). Also, we make
sure that each package works, so an automated process is not going to
help us ;)
Lucas Nussbaum
> On Thu, Mar 18, 2010 at 8:47 PM, Lucas Nussbaum <lu...@lucas-nussbaum.net>wrote:
>
> > On 19/03/10 at 02:49 +0900, Aldric Giacomoni wrote: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.
> >
>
> Can I ask: how do Perl and Python deal with this? CPAN is included in the
> base Perl install - how does Perl deal
> with the fact that CPAN then installs its own stuff?
CPAN only installs its own stuff when the user requests it. However,
most of the useful CPAN is packaged in Debian. Packaging perl modules is
very easy, because:
- they are provided as .tgz
- they all share exactly the same interface for compilation and testing
- that interface doesn't require any external dependencies
(I'm not very familiar with python packaging, but I think that it is
similar)
As a result, Debian currently contains more than 2000 perl libraries,
about 1400 python libraries, and only ~300 ruby libraries.
With ruby libraries:
- it is usually difficult to find a usable source. Sometimes we have to
extract the gem and convert it to a tgz. We also have a service
(githubredir.debian.net) that allows us to fetch a specific tag on
github as a .tgz.
- then we often have to modify the source, to remove the calls to
"require 'rubygems'"
- then we have to find a way to install the files. If the directory
structure uses the setup.rb standard (bin/, lib/, etc...), then it's
easy, and we use our own copy of setup.rb to install everything.
But some libraries don't ship the files in a very organized way.
- Then we have to find a way to run the test suite during the build.
Since all packages in Debian are frequently rebuilt for QA purposes,
it is a good way to detect regressions. Unfortunately, using "rake
test" is usually not an option, because of the way the Rakefile is
written (dependencies on other stuff including rubygems, etc). So, in
most cases, we just run the test manually (cd test ; ./ts_*.rb) or
give up and do not run the test suite automatically during the build.
Also, we would like to support two ruby versions (1.8 and 1.9.X),
which is often difficult because 1.9.X compatibility is rarely
mentioned in the library documentation.
> Is it safe to install RubyGems via apt-get now? I have seen warnings but I
> don't know the actual reason behind them.
Even if I said "yes", I'm probably not the one to trust on that :P
Leslie Viljoen
On Thu, Mar 18, 2010 at 10:07 PM, Lucas Nussbaum
<lu...@lucas-nussbaum.net>wrote:
Ok, I have created a few gems and I wouldn't mind trying to make my gems
more
Debian friendly. Perhaps these guidelines could be put on a wiki, or
something
like Hoe could check for and warn about some of them.
To make a gem, I usually read these:
http://docs.rubygems.org/read/chapter/5
http://nubyonrails.com/articles/tutorial-publishing-rubygems-with-hoe
Eric Hodel
Maybe Debian should switch to a non-GPL readline implementation for ruby as it's not illegal on OS X:
$ otool -L `gem which readline`
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0/readline.bundle:
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.7)
/usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.11.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
(Ignoring compatibility problems between readline and editline, of course)
gf
> [...]
> 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.
Perhaps talking to the gemcutter people (http://rubygems.org/) to
bottleneck the Deb/RPM packaging needs would be productive? That's
supposed to be the source for gems now, so building in a hook that
does all the necessary tweaks for *nix packaging would tie Windows,
Mac OS, gems and Deb/RPM together at the source. Just a thought from
my tired ol' mind.
http://www.rubyinside.com/gemcutter-a-fast-and-easy-approach-to-ruby-gem-hosting-2281.html
http://www.rubyinside.com/gemcutter-is-the-new-official-default-rubygem-host-2659.html
Lucas Nussbaum
It was pointed out that libedit doesn't support multibyte encodings yet,
unfortunately. But yes, it is a solution.
Lucas Nussbaum
> On Mar 18, 11:47 am, Lucas Nussbaum <lu...@lucas-nussbaum.net> wrote:
> > [...]
> > 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.
> [...]
>
> Perhaps talking to the gemcutter people (http://rubygems.org/) to
> bottleneck the Deb/RPM packaging needs would be productive? That's
> supposed to be the source for gems now, so building in a hook that
> does all the necessary tweaks for *nix packaging would tie Windows,
> Mac OS, gems and Deb/RPM together at the source. Just a thought from
> my tired ol' mind.
Yes. I will do that when we have a discussion about that on the Debian
side again (now is not a good time, we are trying to get a release out).
John W Higgins
Good Afternoon,
On Thu, Mar 18, 2010 at 1:07 PM, Lucas Nussbaum <lu...@lucas-nussbaum.net>wrote:
> With ruby libraries:
> - it is usually difficult to find a usable source. Sometimes we have to
> extract the gem and convert it to a tgz. We also have a service
> (githubredir.debian.net) that allows us to fetch a specific tag on
> github as a .tgz.
>
I'm rather confused by this - a gem file (at least as far as I can find)
contains two files data.tar.gz and metadata.tar.gz within the tar.gz shell
of the .gem file - what exactly is the issue with that layout? Is there
something specific that this doesn't provide you that is of great
importance?
> - then we often have to modify the source, to remove the calls to
> "require 'rubygems'"
>
I'm pretty sure that's a one liner for 99.9% of cases and I really don't
think is necessary - you really should look at how Gentoo installs gems
because we get the benefit of both "manually" installing a package as well
as full integration within RubyGems (for example gem list --local shows all
gems installed via portage and well as gem install). If there is no ebuild
file we can infact turn to emerge-gem to take a gem file and create an
ebuild (including full dependency checks from the gem itself). Does it work
every single time - nope - but it seems like a huge improvement over what is
going on with Debian at the moment.
> - then we have to find a way to install the files. If the directory
> structure uses the setup.rb standard (bin/, lib/, etc...), then it's
> easy, and we use our own copy of setup.rb to install everything.
> But some libraries don't ship the files in a very organized way.
>
Again, you keep seeming to want to continue to take shot after shot at
developers when clearly it's an issue with the ability of Debian to have any
flexibility - again looking at Gentoo it somehow, in a very much automated
fashion, manages to handle all these wild and wacky libraries.
In fact you might want to look at Gentoo as a way to create sources packages
because it seems to handle all your issues and will present a nice simple
tar.bz2 package of the files that might be much easier to work with in
regards to your need for standardization. And I'm truly not saying that to
be an idiot or anything - it really seems like Gentoo has solved the issues
you are having, at least with respect to getting the files into some form of
a constant layout which may be of great help to you.
John
Rick DeNatale
<lu...@lucas-nussbaum.net> wrote:
> 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 assume you mean that "the user doesn't care whether it's perl or ruby."
Actually control, or lack of control over configuration management
cuts both ways.
I the case of OO base framework code, you can't safely change versions
of the framework and the application based on the framework. Back in
the late 80s early 90s, everyone got excited over the early
application frameworks like MacApp and NextStep, and all of the guys
developing operating systems got the idea of building operating
systems with frameworks as the API. This just doesn't work. I know,
I was there.
http://talklikeaduck.denhaven2.com/2007/06/15/a-meeting-with-gill-bates
And for those who might be slow, I just switched the first letters in
Gill Bates first and last names. <G>
MacApp, NextStep, and Rails work only when the application can freeze
to a particular version of the framework, moving between versions of
the framework inevitably involves some rewrite of the application.
This is why it's very wise to freeze gems in a Rails application. And
when this is done, by the way, you don't need gems to install the app,
you typically deploy it via checking it out from a source code
repository, and the gems are put in the right place within THAT
APPLICATIONS file hierarchy.
I know folks who've been bitten when they haven't vendored gems and
deployed to a hosting provider, who took it upon themselves to upgrade
the SYSTEM without knowing about the need for independent
configuration management for the customer's application(s).
And other users got bitten when their hosting provider (or they
themselves) upgraded the Ruby 1.8 package and got Ruby 1.8.6 changed
out to 1.8.7 before their code, or rails or ... was compatible with
1.8.7.
Now I know that 1.8.7 maybe shouldn't have made some of the changes it
did, and I argued against this at the time, but it's not a question of
who is to blame, it's a question of recognizing that seeing
configuration management as solely the concern of system
administrators is problematical at best.
Rick DeNatale
Putting my self in Lucas' shoes, I have to say that such advice seems
like telling a Christian that he should accept Mohammed, or an Arab or
Buddhist that If they just accept Jesus as their savior everything
will be all right.
Me, I'm for freedom of religion, as long as I'm free to practice as I wish.
<duck>What have I opened myself up for</duck>
Seriously though. Each distro has it's own philosophy and goals.
Debian tries to balance stability with keeping up with the latest
trends. It appeals to people who like such stability. At times
though this has caused problems, the loooong interlude between Woody
and Sarge caused a lot of folks to champ at the bit for new stuff.
That's one of the reasons Ubuntu got popular, it introduced timeboxed
releases so that one could be assured that one would be getting a
'stable' refresh every 6 months or so, and not have to dip into the
testing or horror of horrors 'sid' version. Canonical was more
aggressive in pulling stuff from the testing branch, reworking it and
contributing it back.
Personally, I use Ubuntu for my linux boxes, but I still use Ruby and
rubygems from source.
Lucas' dilemma is that he is trying to deal with a rapidly moving body
of software in Ruby and particularly ruby gems, in the context of the
conservative debian philosophy.
I don't envy him.
Lucas Nussbaum
> On Thu, Mar 18, 2010 at 2:47 PM, Lucas Nussbaum
> <lu...@lucas-nussbaum.net> wrote:
> > 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 assume you mean that "the user doesn't care whether it's perl or ruby."
Yes. I clearly sent too many mails on this list today, but people keep
replying to me with interesting comments!! ;)
Thanks for the very interesting link.
I understand why it is necessary to freeze the rails version for an
application, and why such framework are a different problem.
However, that's only a small part of the issue: most gems that are
typically vendored are only used through a relatively simple API, and
there's no real reason to vendor and freeze those. And the core+stdlib
don't really have valid reasons for significantly breaking the API,
especially between versions of Ruby 1.8.7.X.
Of course, that requires efforts. But the consequence of not doing that
work is that people tend to stay with ancient versions of the
interpreter, do not consider it interesting to try newer versions, and
we end up with Ruby 1.9: first snapshot package uploaded to Debian 5
years ago, and still not widely used by the Ruby community because the
cost of migration is too high.
Lucas Nussbaum
> Good Afternoon,
>
> On Thu, Mar 18, 2010 at 1:07 PM, Lucas Nussbaum <lu...@lucas-nussbaum.net>wrote:
>
> > With ruby libraries:
> > - it is usually difficult to find a usable source. Sometimes we have to
> > extract the gem and convert it to a tgz. We also have a service
> > (githubredir.debian.net) that allows us to fetch a specific tag on
> > github as a .tgz.
> >
>
> I'm rather confused by this - a gem file (at least as far as I can find)
> contains two files data.tar.gz and metadata.tar.gz within the tar.gz shell
> of the .gem file - what exactly is the issue with that layout? Is there
> something specific that this doesn't provide you that is of great
> importance?
It's just extra work. Also, if I remember correctly, the dates in the
data.tar.gz file are incorrect because of a missing feature in the
pure-ruby tar implementation in rubygems.
I agree that we could have a better infrastructure on the Debian side to
deal with that, and automate many of the tasks. None of the problems are
particularly hard, we just all lack time (and motivation to work on a
somehow poisonous issue).
I really think that, in the end, whether to plug into the gems system
(like Gentoo does) or to leave it for manual installs by the user (like
Debian does) is mainly a matter of taste.
Btw, I see in the github portage tree that former versions for gems are
apparently no longer available. How do you deal with gems that require a
specific (ancient) version of another gem?
Dido Sevilla
<lu...@lucas-nussbaum.net> wrote:
> 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)
http://www.openssl.org/support/faq.html#LEGAL2
"On many systems including the major Linux and BSD distributions, yes
(the GPL does not place restrictions on using libraries that are part
of the normal operating system distribution). "
--
普通じゃないのが当然なら答える私は何ができる？
普通でも普通じゃなくて感じるまま感じることだけをするよ！
http://stormwyrm.blogspot.com
Lucas Nussbaum
> On Thu, Mar 18, 2010 at 11:02 PM, Lucas Nussbaum
> <lu...@lucas-nussbaum.net> wrote:
> > 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)
>
> http://www.openssl.org/support/faq.html#LEGAL2
>
> "On many systems including the major Linux and BSD distributions, yes
> (the GPL does not place restrictions on using libraries that are part
> of the normal operating system distribution). "
Full quote:
"On other systems, the situation is less clear. Some GPL software
copyright holders claim that you infringe on their rights if you use
OpenSSL with their software on operating systems that don't normally
include OpenSSL.
If you develop open source software that uses OpenSSL, you may find it
useful to choose an other license than the GPL, or state explicitly that
"This program is released under the GPL with the additional exemption
that compiling, linking, and/or using OpenSSL is allowed." If you are
using GPL software developed by others, you may want to ask the
copyright holder for permission to use their software with OpenSSL."
Note that the FSF and Debian think that this is a problem.
I'm not sure how the Ruby copyright is managed. If it is possible to
change the license, I would suggest adding a GPL exemption clause (like
wget did, for example), which would clarify the situation.
From wget's README file:
Additional permission under GNU GPL version 3 section 7
If you modify this program, or any covered work, by linking or
combining it with the OpenSSL project's OpenSSL library (or a
modified version of that library), containing parts covered by the
terms of the OpenSSL or SSLeay licenses, the Free Software Foundation
grants you additional permission to convey the resulting work.
Corresponding Source for a non-source form of such a combination
shall include the source code for the parts of OpenSSL used as well
as that of the covered work.
Brian Candler
> 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.
If Debian are worried about infringement, then who do they think is
going to sue them?
(1) The OpenSSL copyright holders?
http://www.openssl.org/support/faq.html#LEGAL2
Clearly, they see it as an issue of the GPL holders needing to extend
their licence, not OpenSSL intending to restrict what GPL authors do.
'If you develop open source software that uses OpenSSL, you may find it
useful to choose an other license than the GPL, or state explicitly that
"This program is released under the GPL with the additional exemption
that compiling, linking, and/or using OpenSSL is allowed."'
Anyway, if the OpenSSL licence requires attribution, surely that applies
only to OpenSSL itself? Do people think that it is viral in the way that
the GPL is viral?
(2) The Ruby/FreeRADIUS/etc people?
Their code explicitly does things like #include <openssl.h>. It is quite
obviously intended to be used and linked with OpenSSL.
They might be worried if someone tried to redistribute Ruby+OpenSSL
under a single combined licence which was more restrictive than the GPL.
But Debian isn't doing that; they aggregate a whole load of software,
each distributed under its own licence. Is there an all-encompassing
"Debian Licence"? I didn't think so, and I wouldn't use Debian/Ubuntu if
I discovered there were.
Lucas Nussbaum
> Austin Ziegler wrote:
> > 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.
>
> If Debian are worried about infringement, then who do they think is
> going to sue them?
>
> (1) The OpenSSL copyright holders?
[..]
> (2) The Ruby/FreeRADIUS/etc people?
[..]
You shouldn't assume that because someone is very friendly now, it will
always be the case. There has been several occurrences of people or
groups changing their mind, because, for a example, a company was bought
by another one with a less friendly position.
Note that Freeradius has a exception for OpenSSL in src/LICENSE.openssl.
Ruby doesn't AFAICS.
> They might be worried if someone tried to redistribute Ruby+OpenSSL
> under a single combined licence which was more restrictive than the GPL.
> But Debian isn't doing that; they aggregate a whole load of software,
> each distributed under its own licence. Is there an all-encompassing
> "Debian Licence"? I didn't think so, and I wouldn't use Debian/Ubuntu if
> I discovered there were.
There isn't.
Brian Candler
> Note that Freeradius has a exception for OpenSSL in src/LICENSE.openssl.
Ah, that's pretty recent, thanks for pointing it out. I look forward to
an EAP-capable freeradius out of the box.
> Ruby doesn't AFAICS.
Has it been requested?
Austin Ziegler
> Austin Ziegler wrote:
>> 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.
> If Debian are worried about infringement, then who do they think is
> going to sue them?
It's subtly more complex than that. While IANAL, I suspect that Debian
and the other distribution managers are fairly safe here since they
don't require that you have OpenSSL by default, and provide OpenSSL as a
dynamically loadable object when requested by the end user (implicitly
or explicitly).
As I said in an earlier message, the FSF takes a maximal view on the
applicability of the GNU GPL, extending to situations that are not
logically covered by the GNU GPL (e.g., run-time combination).
It is fairly clear that if I were to distribute an application that
requires both OpenSSL (with the attribution clauses) and libreadline
(under the GNU GPL), I would be violating the license of one of them or
another (probably the GNU GPL because it has the incompatibility with
attribution requirements).
If, on the other hand, OpenSSL and/or libreadline are optional
components that end users enable at run-time, the situation is likely
the opposite of what the FSF says (that is, no license violation; just
the violation of the spirit of the GNU GPL). By the way, this is one of
the things that annoys me about a lot of GPLed projects on Windows: they
present the GNU GPL as a EULA, when it's completely NOT a EULA.
I do not need to accept the GNU GPL to *use* a piece of software; just
to distribute it. It's arguable that the GNU GPL v3 and the Affero GPL
step into EULA territory by treating networked use as distribution, but
that is an untested area of the licences. More reason to avoid both
versions, IMO.
> (1) The OpenSSL copyright holders?
>
> http://www.openssl.org/support/faq.html#LEGAL2
>
> Clearly, they see it as an issue of the GPL holders needing to extend
> their licence, not OpenSSL intending to restrict what GPL authors do.
They're also right. OpenSSL's license is extremely permissive, even if
the attribution requirement is annoying.
> 'If you develop open source software that uses OpenSSL, you may find
> it useful to choose an other license than the GPL, or state explicitly
> that "This program is released under the GPL with the additional
> exemption that compiling, linking, and/or using OpenSSL is allowed."'
>
> Anyway, if the OpenSSL licence requires attribution, surely that
> applies only to OpenSSL itself? Do people think that it is viral in
> the way that the GPL is viral?
No; the problem is that the GNU GPL does not allow "subordinate"[1]
licences to have any restrictions above and beyond what the GNU GPL has,
"restricting" end-user rights further[2].
-austin
[1] The GNU GPL views all licences in a mixed license bundle as
subordinate to itself, as it's an expansive, viral license[3]. That
is to say that the language of the GNU GPL expects that it will be
the final arbiter of what is permitted and what is not permitted for
a composite work containing GNU GPL software.
[2] In many ways, I agree with this restriction, if not the
implementation. It would be fairly trivial to put language in the
GNU GPL enumerating additional optional exceptions for other 'open'
licences (e.g., attribution clauses). I am not sure that the
original 4-clause BSD license (with advertising attribution clauses)
would pass the GNU GPL with that anyway, nor am I sure that it
should pass.
[3] The GNU GPL is correctly viewed as a viral license in that it
imposes requirements on software that includes software under the
GNU GPL. This virality is a feature of the GNU GPL. It's a feature
that I strongly dislike, but it is exactly the purpose for which the
GNU GPL was written.
Aldric Giacomoni
> On 19/03/10 at 06:44 +0900, John W Higgins wrote:
>
>> ebuild (including full dependency checks from the gem itself). Does it work
>> fashion, manages to handle all these wild and wacky libraries.
>>
>> In fact you might want to look at Gentoo as a way to create sources packages
>> because it seems to handle all your issues and will present a nice simple
>> tar.bz2 package of the files that might be much easier to work with in
>> regards to your need for standardization. And I'm truly not saying that to
>> be an idiot or anything - it really seems like Gentoo has solved the issues
>> you are having, at least with respect to getting the files into some form of
>> a constant layout which may be of great help to you.
Well.. Gentoo also builds from source, so it tends to have all the
header files! In addition, it doesn't shy away from adding requirements
to ebuilds. I had an issue, in fact, where xemacs kept on being
re-installed on my machine, and I eventually tracked the problem down to
a specific USE flag on my (cue suspenseful music) dev-lang/ruby package.
That's right.. Ruby required xemacs;-) I removed the USE flag and xemacs
never came back.
> I agree that we could have a better infrastructure on the Debian side to
> deal with that, and automate many of the tasks. None of the problems are
> particularly hard, we just all lack time (and motivation to work on a
> somehow poisonous issue).
>
> I really think that, in the end, whether to plug into the gems system
> (like Gentoo does) or to leave it for manual installs by the user (like
> Debian does) is mainly a matter of taste.
This is true.
> Btw, I see in the github portage tree that former versions for gems are
> apparently no longer available. How do you deal with gems that require a
> specific (ancient) version of another gem?
Besides the official portage tree, there are overlays; there is an
overlay dedicated to Ruby, which has much more than the regular tree.
You are right, though - there is a limitation, and the limitation always
is "Who has created an ebuild (or .deb package) for this version of the
gem?"
If the version we need isn't in the tree or the overlay, then either we
create an ebuild for it or we install it with rubygems.
Lucas Nussbaum
> Lucas Nussbaum wrote:
> > Note that Freeradius has a exception for OpenSSL in src/LICENSE.openssl.
>
> Ah, that's pretty recent, thanks for pointing it out. I look forward to
> an EAP-capable freeradius out of the box.
>
> > Ruby doesn't AFAICS.
>
> Has it been requested?
http://redmine.ruby-lang.org/issues/show/2982
James Nathan
--- On Thu, 3/18/10, James Edward Gray II <ja...@graysoftinc.com> wrote:
From: James Edward Gray II <ja...@graysoftinc.com>
Subject: Re: Recommended way to install Rubygems
To: "ruby-talk ML" <ruby...@ruby-lang.org>
Date: Thursday, March 18, 2010, 10:01 AM
On Mar 18, 2010, at 10:53 AM, Lucas Nussbaum wrote:
> On 19/03/10 at 00:35 +0900, James Edward Gray II wrote:
>> On Mar 18, 2010, at 10:15 AM, Lucas Nussbaum 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.
>
> 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 Gray II
Robert Dober
<lu...@lucas-nussbaum.net> wrote:
> On 18/03/10 at 17:10 +0900, Ryan Davis wrote:
>>
>> On Mar 18, 2010, at 00:47 , Lucas Nussbaum wrote:
>>
>> > Which parts of ruby which are currently split out would you like to see
>> > installed when the user installs ruby? For example, ruby ships a ruby
>> > emacs mode. Installing that would require adding a dependency on emacs,
>> > which doesn't sound reasonable.
>>
>> That's a bullshit rationalization.
>
> See why I don't want to discuss this? ;-)
Strange, don't you like being insulted? (1)
Anyway as a (thankfull) user of Ruby and Ubuntu I vote against any
preinstalled gem, that is just asking for trouble. For things like
ruby-emacs should that not go into emcas rather?
Cheers
Robert
(1) Depends by whom, I guess ;).
> --
> | Lucas Nussbaum
> | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
> | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
>
>
--
Learning without thought is labor lost; thought without learning is perilous.”
--- Confucius