On Thu, Mar 18, 2010 at 10:21 AM, Lucas Nussbaum
<lucas / lucas-nussbaum.net> wrote:
> On 18/03/10 at 23:05 +0900, Nick Brown wrote:

> 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.


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